Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Sur cette page
 

Configuration LSP de base

Configuration des métriques LSP

La métrique LSP est utilisée pour indiquer la facilité ou la difficulté d’envoyer du trafic sur un LSP particulier. Des valeurs métriques LSP plus faibles (coût inférieur) augmentent la probabilité qu’un LSP soit utilisé. À l’inverse, des valeurs métriques LSP élevées (coût plus élevé) diminuent la probabilité qu’un LSP soit utilisé.

La métrique LSP peut être spécifiée dynamiquement par le routeur ou explicitement par l’utilisateur, comme décrit dans les sections suivantes :

Configuration des métriques LSP dynamiques

Si aucune métrique spécifique n’est configurée, un LSP tente de suivre la métrique IGP vers la même destination (l’adresse to du LSP). IGP comprend OSPF, IS-IS, Routing Information Protocol (RIP) et les routes statiques. BGP et les autres routes RSVP ou LDP sont exclues.

Par exemple, si la métrique OSPF vers un routeur est 20, tous les LSP vers ce routeur héritent automatiquement de la métrique 20. Si l’OSPF vers un routeur passe ultérieurement à une valeur différente, toutes les métriques LSP changent en conséquence. S’il n’y a pas de routes IGP vers le routeur, le LSP augmente sa métrique à 65 535.

Notez que dans ce cas, la métrique LSP est entièrement déterminée par IGP ; il n’a aucun rapport avec le chemin réel que le LSP est en train de parcourir. Si LSP est redirigé (par exemple par le biais d’une réoptimisation), sa métrique ne change pas et reste donc transparente pour les utilisateurs. La métrique dynamique est le comportement par défaut ; Aucune configuration n’est requise.

Configuration des métriques LSP statiques

Vous pouvez attribuer manuellement une valeur de métrique fixe à un LSP. Une fois configurée avec l’instruction metric , la métrique LSP est fixe et ne peut pas changer :

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

La métrique LSP a plusieurs utilisations :

  • Lorsqu’il existe des LSP parallèles avec le même routeur de sortie, les métriques sont comparées pour déterminer lequel LSP a la valeur métrique la plus faible (le coût le plus bas) et donc le chemin préféré vers la destination. Si les métriques sont identiques, le trafic est partagé.

    L’ajustement des valeurs des métriques peut forcer le trafic à préférer certains LSP à d’autres, quelle que soit la métrique IGP sous-jacente.

  • Lorsqu’un raccourci IGP est activé (voir Utilisation de chemins commutés étiquetés pour augmenter SPF pour calculer les raccourcis IGP), un itinéraire IGP peut être installé dans la table de routage avec un LSP comme tronçon suivant, si le LSP se trouve sur le chemin le plus court vers la destination. Dans ce cas, la métrique LSP est ajoutée aux autres métriques IGP pour déterminer la métrique du chemin total. Par exemple, si un LSP dont le routeur entrant est X et le routeur de sortie est Y se trouve sur le chemin le plus court vers la destination Z, la métrique LSP est ajoutée à la métrique de l’itinéraire IGP de Y à Z pour déterminer le coût total du chemin. Si plusieurs LSP sont des sauts suivants potentiels, les métriques totales des chemins sont comparées pour déterminer quel chemin est préféré (c’est-à-dire qui a la métrique totale la plus basse). Les chemins IGP et les LSP menant à la même destination peuvent également être comparés à l’aide de la valeur de la métrique afin de déterminer le chemin à privilégier.

    En ajustant la métrique LSP, vous pouvez forcer le trafic à préférer les LSP, à préférer le chemin IGP ou à partager la charge entre eux.

  • Si les routeurs X et Y sont des homologues BGP et qu’un LSP existe entre eux, la métrique LSP représente le coût total pour atteindre Y à partir de X. Si, pour une raison quelconque, le LSP change de direction, le coût du chemin sous-jacent peut changer de manière significative, mais le coût de X pour atteindre Y reste le même (la métrique LSP), ce qui permet à X de signaler par le biais d’un discriminateur de sortie multiple BGP (MED) une métrique stable aux voisins en aval. Tant que Y reste accessible via le LSP, aucune modification n’est visible pour les voisins BGP en aval.

Il est possible de configurer IS-IS pour ignorer la métrique LSP configurée en incluant l’instruction ignore-lsp-metrics au niveau de la [edit protocols isis traffic-engineering shortcuts] hiérarchie. Cette instruction supprime la dépendance mutuelle entre IS-IS et MPLS pour le calcul des chemins. Pour plus d’informations, reportez-vous à la bibliothèque de protocoles de routage de Junos OS pour les périphériques de routage.

Configuration des métriques conditionnelles RSVP LSP

La métrique conditionnelle permet d’utiliser différentes valeurs de métrique de manière conditionnelle pour les chemins de commutation d’étiquettes (LSP) locaux configurés statiquement. Les mesures conditionnelles sont basées sur la métrique IGP qui change dynamiquement. Junos OS remplace la métrique LSP par la métrique conditionnelle configurée qui correspond au seuil le plus élevé atteint par la métrique IGP. S’il n’y a pas de conditions correspondantes, le LSP utilise la métrique IGP de l’itinéraire. Vous pouvez configurer jusqu’à quatre métriques conditionnelles pour un LSP et elles seront triées dans l’ordre.

Si vous configurez l’instruction track-igp-metric avec la configuration de métrique conditionnelle, Junos OS utilise la métrique IGP des routes installées pour évaluer la métrique conditionnelle configurée. Vous ne pouvez pas configurer la métrique statique avec la métrique conditionnelle.

Préserver la métrique IGP dans les routes RSVP LSP

Lorsque vous utilisez l’instruction conditional-metric pour configurer des LSP RSVP, la métrique résultante peut être différente de la métrique IGP réelle pour la destination LSP. RSVP programme l’itinéraire d’entrée LSP avec cette métrique conditionnelle comme métrique de l’itinéraire. Toutefois, dans certaines situations, il peut être nécessaire de conserver la métrique IGP réelle utilisée par la métrique conditionnelle pour une utilisation ultérieure, telle que le calcul de la valeur BGP MED.

Utilisez l’instruction en conjonction avec l’instruction pour inclure les informations de métrique IGP dans l’itinéraire include-igp-metricconditional-metric RSVP.

Exécutez la show route protocol rsvp extensive commande pour afficher le coût IGP réel mis à jour.

REMARQUE :

Cela ne s’applique qu’aux itinéraires RSVP utilisant la métrique conditionnelle. Les routes RSVP qui utilisent l’IGP dynamique incluent la métrique IGP par défaut.

Pour plus d’informations, consultez l’instruction de include-igp-metric configuration.

Configuration d’une description textuelle pour les prestataires de services linguistiques

Vous pouvez fournir une description textuelle d’un LSP en y joignant tout texte descriptif qui inclut des espaces entre guillemets ( » « ). Le texte descriptif que vous incluez s’affiche dans la sortie détaillée de la commande ou de la show mpls lspshow mpls container-lsp commande.

L’ajout d’une description textuelle pour un LSP n’a aucun effet sur le fonctionnement du LSP. La description textuelle du LSP ne doit pas dépasser 80 caractères.

Pour fournir une description textuelle d’un LSP, incluez l’instruction à l’un description des niveaux hiérarchiques suivants :

Avant de commencer :

  • Configurez les interfaces de l’appareil.

  • Configurez l’appareil pour la communication réseau.

  • Activez MPLS sur les interfaces des appareils.

  • Configurez un LSP dans le domaine MPLS.

Pour ajouter une description textuelle à un prestataire de services linguistiques :

  1. Saisissez n’importe quel texte décrivant le LSP.

    Par exemple :

  2. Vérifiez et validez la configuration.

    Par exemple :

  3. Affichez la description d’un LSP à l’aide de la show mpls lsp detail commande ou show mpls container-lsp detail , en fonction du type de LSP configuré.

Configuration de la préemption logicielle MPLS

La préemption douce tente d’établir un nouveau chemin pour un LSP préempté avant de détruire le LSP d’origine. Le comportement par défaut consiste à supprimer d’abord un LSP préempté, à signaler un nouveau chemin, puis à rétablir le LSP sur le nouveau chemin. Dans l’intervalle qui s’écoule entre le moment où le chemin d’accès est arrêté et l’établissement du nouveau LSP, tout trafic qui tente d’utiliser le LSP est perdu. La préemption douce empêche ce type de perte de trafic. L’inconvénient est que pendant la période où un LSP est préempté en douceur, deux LSP avec leurs besoins de bande passante correspondants sont utilisés jusqu’à ce que le chemin d’origine soit détruit.

La préemption logicielle MPLS est utile pour la maintenance du réseau. Par exemple, vous pouvez éloigner tous les prestataires de services linguistiques d’une interface particulière, puis mettre l’interface hors service pour des raisons de maintenance sans interrompre le trafic. La préemption logicielle MPLS est décrite en détail dans le document RFC 5712, MPLS Traffic Engineering Soft Preemption.

La préemption logicielle est une propriété du LSP et est désactivée par défaut. Vous le configurez à l’entrée d’un LSP en incluant l’instruction soft-preemption :

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

Vous pouvez également configurer un minuteur pour la préemption douce. Le minuteur indique la durée pendant laquelle le routeur doit attendre avant de lancer une préemption stricte du LSP. À la fin du temps spécifié, le LSP est démonté et resignalé. Le minuteur de nettoyage par préemption logicielle a une valeur par défaut de 30 secondes ; La plage de valeurs autorisées est comprise entre 0 et 180 secondes. Une valeur de 0 signifie que la préemption douce est désactivée. Le minuteur de nettoyage à préemption douce est global pour tous les LSP.

Configurez le minuteur en incluant l’instruction cleanup-timer :

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

REMARQUE :

La préemption logicielle ne peut pas être configurée sur les LSP pour lesquels un reroutage rapide a été configuré. La validation de la configuration échoue. Toutefois, vous pouvez activer la préemption logicielle en conjonction avec la protection des nœuds et des liens.

REMARQUE :

La valeur du compteur pour SoftPreemptionCnt s’initialise avec une valeur de 0 (zéro), visible dans la sortie de la commande show rsvp interface detail .

Configuration de la priorité et de la préemption pour les LSP

Lorsque la bande passante est insuffisante pour établir un LSP plus important, vous pouvez supprimer un LSP existant moins important pour libérer la bande passante. Pour ce faire, préemptez le prestataire de services linguistiques existant.

La question de savoir si un LSP peut être préempté est déterminée par deux propriétés associées au LSP :

  • Setup priority (Priorité de configuration) : détermine si un nouveau LSP qui préempte un LSP existant peut être établi. Pour que la préemption se produise, la priorité de configuration du nouveau LSP doit être supérieure à celle du LSP existant. De plus, le fait de préempter le LSP existant doit produire une bande passante suffisante pour prendre en charge le nouveau LSP. C’est-à-dire que la préemption ne se produit que si le nouveau LSP peut être configuré avec succès.

  • Priorité de réservation : détermine le degré auquel un prestataire de services linguistiques conserve sa réservation de session une fois qu’il a été configuré avec succès. Lorsque la priorité de réservation est élevée, le prestataire de services linguistiques existant est moins susceptible d’abandonner sa réservation, et il est donc peu probable qu’il puisse être préempté.

Vous ne pouvez pas configurer un LSP avec une priorité de configuration élevée et une priorité de réservation faible, car des boucles de préemption permanentes peuvent se produire si deux LSP sont autorisés à se préempter mutuellement. Vous devez configurer la priorité de réservation pour qu’elle soit supérieure ou égale à la priorité de configuration.

La priorité de configuration définit également l’importance relative des LSP sur le même routeur entrant. Au démarrage du logiciel, lors de l’établissement d’un nouveau LSP ou lors de la récupération d’une panne, la priorité de configuration détermine l’ordre dans lequel les LSP sont traités. Les LSP de priorité plus élevée ont tendance à être établis en premier et bénéficient donc d’une sélection de chemin plus optimale.

Pour configurer les propriétés de préemption du LSP, incluez l’instruction priority suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Les deux setup-priority et peuvent être une valeur comprise entre 0 et reservation-priority 7. La valeur 0 correspond à la priorité la plus élevée et la valeur 7 à la priorité la plus basse. Par défaut, un LSP a une priorité de configuration de 7 (c’est-à-dire qu’il ne peut pas préempter d’autres LSP) et une priorité de réservation de 0 (c’est-à-dire que les autres LSP ne peuvent pas le préempter). Ces valeurs par défaut sont telles qu’il n’y a pas de préemption. Lorsque vous configurez ces valeurs, la priorité de configuration doit toujours être inférieure ou égale à la priorité de maintien.

Configuration des groupes d’administration pour les prestataires de services linguistiques

Les groupes d’administration, également connus sous le nom de coloration des liens ou de classe de ressources, se voient attribuer manuellement des attributs qui décrivent la « couleur » des liens, de sorte que les liens de la même couleur appartiennent conceptuellement à la même classe. Vous pouvez utiliser des groupes d’administration pour implémenter diverses configurations LSP basées sur des stratégies.

Les groupes d’administration n’ont de sens que lorsque le calcul LSP à chemin contraint est activé.

Vous pouvez attribuer jusqu’à 32 noms et valeurs (compris entre 0 et 31), qui définissent une série de noms et leurs valeurs correspondantes. Les noms et valeurs administratifs doivent être identiques sur tous les routeurs d’un même domaine.

REMARQUE :

La valeur administrative est distincte de la priorité. Vous configurez la priorité d’un LSP à l’aide de l’instruction priority . Reportez-vous à la section Configuration de la priorité et de la préemption pour les LSP.

Pour configurer des groupes d’administration, procédez comme suit :

  1. Définissez plusieurs niveaux de qualité de service en incluant l’instruction admin-groups suivante :

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

    • [edit protocols mpls]

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

    L’exemple de configuration suivant illustre comment vous pouvez configurer un ensemble de noms et de valeurs administratifs pour un domaine :

  2. Définissez les groupes d’administration auxquels appartient une interface. Vous pouvez affecter plusieurs groupes à une interface. Incluez l’énoncé interface suivant :

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

    • [edit protocols mpls]

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

    Si vous n’incluez pas l’instruction admin-group , une interface n’appartient à aucun groupe.

    Les IGP utilisent les informations de groupe pour créer des paquets à l’état de lien, qui sont ensuite inondés dans tout le réseau, fournissant des informations à tous les nœuds du réseau. Sur n’importe quel routeur, la topologie IGP, ainsi que les groupes d’administration de toutes les liaisons, sont disponibles.

    La modification du groupe d’administration de l’interface n’affecte que les nouveaux LSP. Les LSP existants sur l’interface ne sont pas préemptés ou recalculés pour maintenir la stabilité du réseau. Si des LSP doivent être supprimés en raison d’un changement de groupe, exécutez la clear rsvp session commande.

    REMARQUE :

    Lors de la configuration simultanée de groupes d’administration et de groupes d’administration étendus pour une liaison, les deux types de groupes d’administration doivent être configurés sur l’interface.

  3. Configurez une contrainte de groupe d’administration pour chaque LSP ou pour chaque chemin d’accès LSP principal ou secondaire. Incluez l’énoncé label-switched-path suivant :

    Vous pouvez inclure l’instruction label-switched-path aux niveaux hiérarchiques suivants :

    • [edit protocols mpls]

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

    Si vous omettez les include-allinstructions , ou , include-anyle exclude calcul du chemin d’accès se poursuit sans modification. Le calcul du chemin est basé sur le calcul LSP du chemin contraint. Pour plus d’informations sur le calcul du LSP à chemin contraint, consultez Comment CSPF sélectionne un chemin.

    REMARQUE :

    La modification du groupe d’administration du LSP entraîne un recalcul immédiat de l’itinéraire ; par conséquent, le LSP peut être réacheminé.

Configuration de groupes d’administration étendus pour les prestataires de services linguistiques

Dans les aspects techniques du trafic MPLS, une liaison peut être configurée avec un ensemble de groupes d’administration (également appelés couleurs ou classes de ressources). Les groupes administratifs sont transportés dans le protocole IGP (Interior Gateway Protocol) (OSPFv2 et IS-IS) sous la forme d’une valeur de 32 bits attribuée à chaque liaison. Les routeurs Juniper Networks interprètent normalement cette valeur de 32 bits comme un masque de bits, chaque bit représentant un groupe, limitant chaque réseau à un total de 32 groupes administratifs distincts (plage de valeurs comprise entre 0 et 31).

Vous configurez des groupes d’administration étendus, représentés par une valeur de 32 bits, ce qui permet d’étendre le nombre de groupes d’administration pris en charge dans le réseau au-delà de 32. La plage de valeurs d’origine disponible pour les groupes d’administration est toujours prise en charge à des fins de rétrocompatibilité.

La configuration des groupes d’administration étendue accepte un ensemble d’interfaces avec un ensemble correspondant de noms de groupes d’administration étendus. Il convertit les noms en un ensemble de valeurs 32 bits et propage ces informations dans l’IGP. Les valeurs du groupe d’administration étendu sont globales et doivent être configurées de manière identique sur tous les routeurs pris en charge participant au réseau. La base de données des groupes d’administration étendus à l’échelle du domaine, apprise d’autres routeurs via le flooding IGP, est utilisée par le programme CSPF (Constrained Shortest Path First) pour le calcul des chemins.

La procédure suivante décrit comment configurer les groupes d’administration étendus :

  1. Configurez l’instruction admin-groups-extended-range :

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

    • [edit routing-options]

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

    L’instruction admin-groups-extended-range inclut les minimum options et maximum . La plage maximale doit être supérieure à la plage minimale.

  2. Configurez l’instruction admin-groups-extended :

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

    • [edit routing-options]

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

    L’instruction admin-groups-extended vous permet de configurer un nom de groupe et une valeur de groupe pour le groupe d’administration. La valeur du groupe doit se trouver dans la plage de valeurs configurée à l’aide de l’instruction admin-groups-extended-range .

  3. Les groupes d’administration étendus d’une interface MPLS sont constitués de l’ensemble des noms de groupes d’administration étendus attribués à l’interface. Les noms des groupes d’administration étendus de l’interface doivent être configurés pour les groupes d’administration étendus globaux.

    Pour configurer un groupe d’administration étendu pour une interface MPLS, spécifiez le nom du groupe d’administration dans la configuration de l’interface MPLS à l’aide de l’instruction admin-groups-extended :

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

    • [edit protocols mpls interface interface-name]

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

  4. Les groupes administratifs étendus LSP définissent l’ensemble des contraintes d’inclusion et d’exclusion d’un LSP et des chemins principal et secondaire d’un chemin. Les noms des groupes d’administration étendus doivent être configurés pour les groupes d’administration étendus globaux.

    Pour configurer des groupes d’administration étendus pour un prestataire de services linguistiques, incluez l’instruction au niveau de la hiérarchie d’un admin-group-extended fournisseur de services linguistiques :

    La admin-group-extended déclaration comprend les options suivantes : apply-groups, , , , apply-groups-exceptexcludeinclude-allet include-any. Chaque option vous permet de configurer un ou plusieurs groupes d’administration étendus.

    Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez configurer cette instruction, reportez-vous au résumé de cette instruction.

  5. Pour afficher les groupes d’administration étendus actuellement configurés, exécutez la show mpls admin-groups-extended commande.
REMARQUE :

Lors de la configuration simultanée de groupes d’administration et de groupes d’administration étendus pour une liaison, les deux types de groupes d’administration doivent être configurés sur l’interface.

Configuration des valeurs de préférence pour les LSP

En option, vous pouvez configurer plusieurs LSP entre la même paire de routeurs entrants et sortants. Ceci est utile pour équilibrer la charge entre les LSP, car tous les LSP, par défaut, ont le même niveau de préférence. Pour préférer un LSP à un autre, définissez différents niveaux de préférence pour chaque LSP. Le LSP avec la valeur de préférence la plus faible est utilisé. La préférence par défaut pour les LSP RSVP est 7 et pour les LSP LDP est 9. Ces valeurs de préférence sont inférieures (plus préférées) à toutes les routes apprises, à l’exception des routes d’interface directe.

Pour modifier la valeur de préférence par défaut, incluez l’instruction preference suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Désactivation de l’enregistrement de route de chemin par les LSP

L’implémentation Junos de RSVP prend en charge l’objet Record Route, qui permet à un prestataire de services linguistiques d’enregistrer activement les routeurs par lesquels il transite. Vous pouvez utiliser ces informations pour le dépannage et pour éviter les boucles de routage. Par défaut, les informations d’itinéraire sont enregistrées. Pour désactiver l’enregistrement, incluez l’instruction no-record suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure les record instructions et no-record , reportez-vous à la section Résumé de l’instruction.

Réussir une transition sans impact pour les prestataires de services linguistiques

Les chemins adaptatifs de commutation d’étiquettes (LSP) peuvent avoir besoin d’établir une nouvelle instance LSP et de transférer le trafic d’une ancienne instance LSP vers la nouvelle instance LSP avant de démanteler l’ancienne. Ce type de configuration est appelé « make before break » (MBB).

RSVP-TE est un protocole utilisé pour établir des LSP dans les réseaux MPLS. L’implémentation Junos OS de RSVP-TE pour obtenir un basculement MBB sans impact (sans perte de trafic) s’est appuyée sur la configuration des valeurs de temporisation dans les instructions de configuration suivantes :

  • optimize-switchover-delay: durée d’attente avant de basculer vers la nouvelle instance LSP.

  • optimize-hold-dead-delay: durée d’attente après le basculement et avant la suppression de l’ancienne instance LSP.

Les instructions et optimize-switchover-delayoptimize-hold-dead-delay s’appliquent à tous les LSP qui utilisent le comportement make-before-break pour la configuration et le démontage des LSP, et pas seulement aux LSP pour lesquels l’instruction optimize-timer a également été configurée. Les fonctionnalités MPLS suivantes entraînent la configuration et la destruction des LSP à l’aide d’un comportement de création avant rupture :

  • LSP adaptatifs

  • Allocation automatique de la bande passante

  • BFD pour les prestataires de services linguistiques

  • Basculement progressif du moteur de routage

  • Protection des liens et des nœuds

  • Routage actif non-stop

  • LSP optimisés

  • LSP point à multipoint (P2MP)

  • Préemption douce

  • Chemins secondaires de secours

Les instructions etoptimize-hold-dead-delay, lorsqu’elles optimize-switchover-delay sont configurées, ajoutent un délai artificiel au processus MBB. La valeur de l’instruction optimize-switchover-delay varie en fonction de la taille des objets de route explicite (ERO). Un ERO est une extension de RSVP qui permet à un message RSVP PATH de traverser une séquence explicite de routeurs indépendante du routage IP conventionnel du chemin le plus court. La valeur de l’instruction optimize-switchover-delay dépend également de la charge CPU sur chacun des routeurs sur le chemin. Les clients définissent la optimize-switchover-delay déclaration par essais et erreurs.

La valeur de l’instruction optimize-hold-dead-delay dépend de la vitesse à laquelle le routeur entrant déplace tous les préfixes d’application pour pointer vers le nouveau LSP. Ceci est déterminé par la charge du moteur de transfert de paquets, qui peut varier d’une plate-forme à l’autre. Les clients doivent définir la optimize-hold-dead-delay déclaration par essais et erreurs.

Toutefois, à partir de la version 15.1, Junos OS est capable de réaliser un basculement MBB sans heurt sans configurer les retards artificiels que de telles valeurs de temporisation introduisent.

Cette rubrique résume les trois méthodes de basculement MBB d’un ancien LSP vers un nouveau LSP à l’aide de Junos OS :

Spécification du temps d’attente du routeur pour basculer vers de nouveaux chemins

Pour spécifier la durée pendant laquelle le routeur attend pour basculer les instances LSP vers les chemins nouvellement optimisés, utilisez l’instruction optimize-switchover-delay . Vous avez uniquement besoin de configurer cette instruction sur les routeurs faisant office d’entrée pour les LSP concernés (vous n’avez pas besoin de configurer cette instruction sur les routeurs de transit ou de sortie). Le minuteur de cette instruction permet de s’assurer que les nouveaux chemins optimisés ont été établis avant que le trafic ne soit basculé à partir des anciens chemins. Ce minuteur ne peut être activé ou désactivé que pour tous les LSP configurés sur le routeur.

Pour configurer la durée d’attente du routeur avant de basculer les instances LSP vers les chemins nouvellement optimisés, spécifiez la durée en secondes à l’aide de l’instruction optimize-switchover-delay :

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

  • [edit protocols mpls]

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

Spécification de la durée pendant laquelle il faut retarder le démantèlement des anciens chemins

Pour spécifier la durée pendant laquelle il faut retarder l’interruption des anciens chemins une fois que le routeur a basculé le trafic vers de nouveaux chemins optimisés, utilisez l’instruction optimize-hold-dead-delay . Vous avez uniquement besoin de configurer cette instruction sur les routeurs faisant office d’entrée pour les LSP concernés (vous n’avez pas besoin de configurer cette instruction sur les routeurs de transit ou de sortie). Le minuteur de cette instruction permet de s’assurer que les anciens chemins ne sont pas supprimés avant que tous les itinéraires n’aient été basculés vers les nouveaux chemins optimisés. Ce minuteur peut être activé pour des LSP spécifiques ou pour tous les LSP configurés sur le routeur.

Pour configurer la durée en secondes permettant de retarder la suppression des anciens chemins une fois que le routeur a basculé le trafic vers de nouveaux chemins optimisés, utilisez l’instruction optimize-hold-dead-delay suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Passer au MBB sans heurts et sans retards artificiels

À partir de la version 15.1 de Junos OS, il existe un autre moyen d’abandonner les anciennes instances LSP après le basculement MBB sans s’appuyer sur les intervalles de temps arbitraires définis par l’instruction optimize-switchover-delay or optimize-hold-dead-delay . Par exemple, si vous utilisez l’instruction, vous configurez une heure que vous pensez qu’il est prudent d’attendre avant de démanteler l’ancienne optimize-hold-dead-delay instance LSP après MBB. Toutefois, il se peut que certaines routes soient encore en cours de transition vers la nouvelle instance. La suppression prématurée de l’ancienne instance LSP entraîne l’abandon prématuré par l’un des nœuds de transit du trafic pour les itinéraires qui n’ont pas été transférés vers la nouvelle instance LSP.

Pour éviter toute perte de trafic, au lieu d’utiliser l’instruction optimize-switchover-delay , vous pouvez utiliser MPLS-OAM (ping lsp), qui confirme que le plan de données LSP est établi de bout en bout. Au lieu d’utiliser l’instruction, vous pouvez utiliser un mécanisme de rétroaction de l’infrastructure rpd qui confirme que tous les préfixes faisant référence à l’ancien optimize-hold-dead-delay LSP ont été basculés. Le mécanisme de rétroaction provient de la bibliothèque de balises et s’appuie sur l’infrastructure rpd (routing protocol process) pour déterminer quand toutes les routes utilisant l’ancienne instance LSP ont été complètement transférées vers la nouvelle instance LSP après le basculement MBB.

Le mécanisme de rétroaction est toujours en place, et il est facultatif. Configurez l’instruction optimize-adaptive-teardown pour que le mécanisme de rétroaction soit utilisé lors du basculement MBB. Cette fonctionnalité n’est pas prise en charge pour les instances LSP point à multipoint (P2MP) RSVP. La configuration globale de l’instruction optimize-adaptive-teardown n’affecte que les LSP point à point configurés dans le système.

Il vous suffit de configurer l’instruction sur les routeurs faisant office d’entrée pour les LSP concernés (vous n’avez optimize-adaptive-teardown pas besoin de configurer cette instruction sur les routeurs de transit ou de sortie). Ce mécanisme de rétroaction garantit que les anciens chemins ne sont pas détruits avant que tous les itinéraires n’aient été basculés vers les nouveaux chemins optimisés. La configuration globale de cette instruction de configuration affecte uniquement les LSP point à point configurés dans le système.

Vous pouvez inclure cette instruction au niveau de la [edit protocols mpls] hiérarchie.

Optimisation des LSP signalés

Une fois qu’un LSP a été établi, des changements de topologie ou de ressources peuvent, au fil du temps, rendre le chemin sous-optimal. Il se peut qu’un nouveau chemin soit disponible, moins encombré, doté d’une métrique plus faible et traversant moins de sauts. Vous pouvez configurer le routeur pour qu’il recalcule régulièrement les chemins afin de déterminer si un chemin plus optimal est désormais disponible.

Si la réoptimisation est activée, un LSP peut être réacheminé à travers différents chemins par des recalculs de chemin contraint. Toutefois, si la réoptimisation est désactivée, le LSP dispose d’un chemin fixe et ne peut pas tirer parti des ressources réseau nouvellement disponibles. Le LSP est fixe jusqu’à ce que le prochain changement de topologie interrompe le LSP et force un recalcul.

La réoptimisation n’est pas liée au basculement. Un nouveau chemin est toujours calculé lorsque des défaillances de topologie se produisent et perturbent un chemin établi.

En raison de la surcharge potentielle du système, vous devez contrôler soigneusement la fréquence de réoptimisation. La stabilité du réseau peut être affectée lorsque la réoptimisation est activée. Par défaut, l’instruction est définie sur 0 (c’est-à-dire qu’elle optimize-timer est désactivée).

L’optimisation LSP n’a de sens que lorsque le calcul LSP à chemin contraint est activé, ce qui est le comportement par défaut. Pour plus d’informations sur le calcul du LSP à chemin contraint, consultez Désactivation du calcul du LSP à chemin contraint. En outre, l’optimisation LSP ne s’applique qu’aux LSP entrants, il suffit donc de configurer l’instruction optimize-timer sur le routeur entrant. Les routeurs de transit et de sortie ne nécessitent aucune configuration spécifique pour prendre en charge l’optimisation LSP (si MPLS est activé).

Pour activer la réoptimisation du chemin, incluez l’instruction optimize-timer suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Une fois que vous avez configuré l’instruction, le minuteur de réoptimisation poursuit son compte à rebours jusqu’à optimize-timer la valeur configurée, même si vous supprimez l’instruction optimize-timer de la configuration. L’optimisation suivante utilise la nouvelle valeur. Vous pouvez forcer Junos OS à utiliser une nouvelle valeur immédiatement en supprimant l’ancienne valeur, en validant la configuration, en configurant la nouvelle valeur pour l’instruction optimize-timer , puis en validant à nouveau la configuration.

Une fois la réoptimisation exécutée, le résultat n’est accepté que s’il répond aux critères suivants :

  1. Le nouveau chemin n’est pas plus élevé en métrique IGP. (La métrique de l’ancien chemin est mise à jour pendant le calcul, donc si une métrique de lien récent a changé quelque part le long de l’ancien chemin, elle est prise en compte.)

  2. Si le nouveau chemin a la même métrique IGP, il n’y a pas plus de sauts.

  3. Le nouveau chemin n’entraîne pas de préemption. (Il s’agit de réduire l’effet d’entraînement de la préemption, ce qui entraîne une plus grande préemption.)

  4. La nouvelle voie n’aggrave pas la congestion dans l’ensemble.

    L’encombrement relatif du nouveau trajet est déterminé comme suit :

    1. Le pourcentage de bande passante disponible sur chaque liaison traversée par le nouveau chemin est comparé à celui de l’ancien chemin, en commençant par les liens les plus encombrés.

    2. Pour chaque (ancien) chemin actuel, le logiciel stocke les quatre plus petites valeurs de disponibilité de la bande passante pour les liens traversés dans l’ordre croissant.

    3. Le logiciel stocke également les quatre plus petites valeurs de disponibilité de la bande passante pour le nouveau chemin, correspondant aux liens traversés dans l’ordre croissant.

    4. Si l’une des quatre nouvelles valeurs de bande passante disponibles est inférieure à l’une des anciennes valeurs de disponibilité de bande passante correspondantes, cela signifie qu’au moins une liaison du nouveau chemin est plus encombrée que la liaison utilisée par l’ancien chemin. L’utilisation de la liaison entraînerait davantage d’encombrement, le trafic n’est pas basculé sur ce nouveau chemin.

    5. Si aucune des quatre nouvelles valeurs de bande passante disponibles n’est inférieure aux anciennes valeurs de disponibilité de bande passante correspondantes, le nouveau chemin est moins encombré que l’ancien.

Lorsque toutes les conditions ci-dessus sont remplies, alors :

  1. Si la métrique IGP du nouveau chemin est inférieure, elle est acceptée.

  2. Si le nouveau chemin a une métrique IGP égale et un nombre de sauts inférieur, il est accepté.

  3. Si vous choisissez least-fill un algorithme d’équilibrage de charge, les LSP sont équilibrés en charge comme suit :

    1. Le LSP est déplacé vers un nouveau chemin qui est utilisé au moins 10 % moins cher que le chemin actuel. Cela pourrait réduire la congestion sur le chemin actuel dans une faible mesure. Par exemple, si un LSP avec 1 Mo de bande passante est déplacé hors d’un chemin portant au moins 200 Mo, l’encombrement sur le chemin d’origine est réduit de moins de 1 %.

    2. Pour random les algorithmes ou most-fill , cette règle ne s’applique pas.

    L’exemple suivant illustre le fonctionnement de l’algorithme d’équilibrage least-fill de charge.

    Figure 1 : Exemple d’algorithme d’équilibrage de charge avec le moindre remplissageExemple d’algorithme d’équilibrage de charge avec le moindre remplissage

    Comme illustré à la section , il existe deux chemins potentiels permettant à un LSP de passer du routeur A au routeur H : les liens impairs de L1 à L13 et les liens pairs de L2 à Figure 1L14. Actuellement, le routeur utilise les liens pairs comme chemin actif pour le LSP. Chaque liaison entre les deux mêmes routeurs (par exemple, le routeur A et le routeur B) a la même bande passante :

    • L1, L2 = 10GE

    • L3, L4 = 1GE

    • L5, L6 = 1GE

    • L7, L8 = 1GE

    • L9, L10 = 1GE

    • L11, L12 = 10GE

    • L13, L14 = 10GE

    Les liaisons 1GE sont plus susceptibles d’être encombrées. Dans cet exemple, les liaisons 1GE impaires ont la bande passante disponible suivante :

    • L3 = 41%

    • L5 = 56%

    • L7 = 66%

    • L9 = 71%

    Les liaisons 1GE paires ont la bande passante disponible suivante :

    • L4 = 37%

    • L6 = 52%

    • L8 = 61%

    • L10 = 70%

    Sur la base de ces informations, le routeur calcule la différence de bande passante disponible entre les liaisons paires et impaires comme suit :

    • L4 - L3 = 41% - 37% = 4%

    • L6 - L5 = 56% - 52% = 4%

    • L8 - L7 = 66% - 61% = 5%

    • L10 - L9 = 71% - 70% = 1%

    La bande passante supplémentaire totale disponible sur les liaisons impaires est de 14 % (4 % + 4 % + 5 % + 1 %). Étant donné que 14 % est supérieur à 10 % (le seuil minimum de l’algorithme de moindre remplissage), le LSP est déplacé vers le nouveau chemin sur les liens impairs du chemin d’origine à l’aide des liens pairs.

  4. Dans le cas contraire, le nouveau chemin est rejeté.

Vous pouvez désactiver les critères de réoptimisation suivants (un sous-ensemble des critères répertoriés précédemment) :

  • Si le nouveau chemin a la même métrique IGP, il n’y a pas plus de sauts.

  • Le nouveau chemin n’entraîne pas de préemption. (Il s’agit de réduire l’effet d’entraînement de la préemption, ce qui entraîne une plus grande préemption.)

  • La nouvelle voie n’aggrave pas la congestion dans l’ensemble.

  • Si le nouveau chemin a une métrique IGP égale et un nombre de sauts inférieur, il est accepté.

Pour les désactiver, exécutez la clear mpls lsp optimize-aggressive commande ou incluez l’instruction optimize-aggressive :

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

  • [edit protocols mpls]

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

L’inclusion de l’instruction dans la configuration entraîne le déclenchement plus fréquent de optimize-aggressive la procédure de réoptimisation. Les chemins sont réacheminés plus fréquemment. Il limite également l’algorithme de réoptimisation à la métrique IGP uniquement.

Configuration du minuteur Smart Optimize pour les LSP

En raison des contraintes liées aux ressources du réseau et du routeur, il est généralement déconseillé de configurer un intervalle court pour le minuteur d’optimisation. Toutefois, dans certaines circonstances, il peut être souhaitable de réoptimiser un chemin plus tôt que ne le ferait normalement le temporisateur d’optimisation.

Par exemple, un LSP traverse un chemin préféré qui échoue par la suite. Le LSP est ensuite basculé vers un chemin moins souhaitable pour atteindre la même destination. Même si le chemin d’origine est rapidement restauré, il peut s’écouler un temps trop long avant que le LSP ne l’utilise à nouveau, car il doit attendre le minuteur d’optimisation pour réoptimiser les chemins réseau. Pour de telles situations, vous souhaiterez peut-être configurer le minuteur d’optimisation intelligent.

Lorsque vous activez le minuteur d’optimisation intelligent, un LSP revient à son chemin d’origine tant que le chemin d’origine a été restauré dans les 3 minutes suivant la descente. De plus, si le chemin d’origine tombe à nouveau en panne dans les 60 minutes, le minuteur d’optimisation intelligent est désactivé et l’optimisation du chemin se comporte comme elle le fait normalement lorsque le minuteur d’optimisation seul est activé. Cela empêche le routeur d’utiliser une liaison battante.

La minuterie d’optimisation intelligente dépend d’autres fonctionnalités MPLS pour fonctionner correctement. Pour le scénario décrit ici dans lequel un LSP est basculé vers un autre chemin en cas de défaillance sur le chemin d’origine, il est supposé que vous avez configuré une ou plusieurs des fonctionnalités de protection du trafic MPLS, y compris le reroutage rapide, la protection de liaison et les chemins secondaires de secours. Ces fonctionnalités permettent de s’assurer que le trafic peut atteindre sa destination en cas de panne.

Au minimum, vous devez configurer un chemin secondaire de secours pour que la fonction de minuterie d’optimisation intelligente fonctionne correctement. Le reroutage rapide et la protection des liaisons sont des solutions temporaires à une panne de réseau. Un chemin secondaire garantit l’existence d’un chemin alternatif stable en cas de défaillance du chemin principal. Si vous n’avez configuré aucune sorte de protection du trafic pour un LSP, le minuteur d’optimisation intelligent ne garantit pas à lui seul que le trafic peut atteindre sa destination. Pour plus d’informations sur la protection du trafic MPLS, reportez-vous à la section MPLS et protection du trafic.

Lorsqu’un chemin principal tombe en panne et que le minuteur d’optimisation intelligent bascule le trafic vers le chemin secondaire, le routeur peut continuer à utiliser le chemin secondaire même après la restauration du chemin principal. Si le routeur entrant effectue un calcul CSPF, il peut déterminer que le chemin secondaire est le meilleur chemin.

Cela peut être indésirable si le chemin principal doit être le chemin actif et que le chemin secondaire doit être utilisé comme chemin de secours uniquement. De plus, si le chemin secondaire est utilisé comme chemin actif (même si le chemin principal a été rétabli) et que le chemin secondaire échoue, la fonctionnalité de minuterie d’optimisation intelligente ne rebascule pas automatiquement le trafic vers le chemin principal. Toutefois, vous pouvez activer la protection du chemin secondaire en configurant la protection des nœuds et des liens ou un chemin secondaire de secours supplémentaire, auquel cas le minuteur d’optimisation intelligent peut être efficace.

Spécifiez la durée en secondes de la minuterie d’optimisation intelligente à l’aide de l’instruction smart-optimize-timer :

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

  • [edit protocols mpls]

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

Limitation du nombre de sauts dans les LSP

Par défaut, chaque LSP peut parcourir un maximum de 255 sauts, y compris les routeurs d’entrée et de sortie. Pour modifier cette valeur, incluez l’instruction hop-limit suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Le nombre de houblons peut être compris entre 2 et 255. (Un chemin avec deux sauts se compose uniquement des routeurs d’entrée et de sortie.)

Configuration de la valeur de bande passante pour les LSP

Chaque LSP a une valeur de bande passante. Cette valeur est incluse dans le champ Tspec de l’expéditeur dans les messages de configuration du chemin RSVP. Vous pouvez spécifier une valeur de bande passante en bits par seconde. Si vous configurez plus de bande passante pour un LSP, celui-ci devrait être en mesure de transporter un plus grand volume de trafic. La bande passante par défaut est de 0 bit par seconde.

Une bande passante différente de zéro nécessite que les routeurs de transit et de sortie réservent la capacité le long des liens sortants pour le chemin. Le système de réservation RSVP est utilisé pour réserver cette capacité. Tout échec dans la réservation de bande passante (par exemple, les échecs au niveau du contrôle de la stratégie RSVP ou du contrôle d’admission) peut entraîner l’échec de la configuration du LSP. S’il n’y a pas suffisamment de bande passante sur les interfaces pour les routeurs de transit ou de sortie, le LSP n’est pas établi.

Pour spécifier une valeur de bande passante pour un LSP signalé, incluez l’instruction bandwidth suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Allocation automatique de la bande passante pour les LSP

L’allocation automatique de la bande passante permet à un tunnel MPLS d’ajuster automatiquement son allocation de bande passante en fonction du volume de trafic circulant dans le tunnel. Vous pouvez configurer un LSP avec une bande passante minimale. cette fonctionnalité permet d’ajuster dynamiquement l’allocation de bande passante du LSP en fonction des modèles de trafic actuels. Les ajustements de bande passante n’interrompent pas le flux de trafic dans le tunnel.

Vous définissez un intervalle d’échantillonnage sur un LSP configuré avec l’allocation automatique de bande passante. La bande passante moyenne est surveillée pendant cet intervalle. À la fin de l’intervalle, on tente de signaler un nouveau chemin pour le LSP en définissant l’allocation de bande passante sur la valeur moyenne maximale de l’intervalle d’échantillonnage précédent. Si le nouveau chemin est établi avec succès et que le chemin d’origine est supprimé, le LSP est basculé vers le nouveau chemin. Si aucun nouveau chemin n’est créé, le LSP continue d’utiliser son chemin actuel jusqu’à la fin de l’intervalle d’échantillonnage suivant, lorsqu’une autre tentative est faite pour établir un nouveau chemin. Notez que vous pouvez définir des valeurs de bande passante minimales et maximales pour le LSP.

Au cours de l’intervalle d’allocation automatique de la bande passante, le routeur peut recevoir une augmentation constante du trafic (augmentation de l’utilisation de la bande passante) sur un LSP, ce qui peut entraîner une congestion ou une perte de paquets. Pour éviter cela, vous pouvez définir un deuxième déclencheur pour faire expirer prématurément le minuteur de réglage automatique de la bande passante avant la fin de l’intervalle de réglage actuel.

Configuration de l’allocation automatique de bande passante pour les LSP

L’allocation automatique de la bande passante permet à un tunnel MPLS d’ajuster automatiquement son allocation de bande passante en fonction du volume de trafic circulant dans le tunnel. Vous pouvez configurer un LSP avec une bande passante minimale, et cette fonctionnalité peut ajuster dynamiquement l’allocation de bande passante du LSP en fonction des modèles de trafic actuels. Les ajustements de bande passante n’interrompent pas le flux de trafic dans le tunnel.

À la fin de l’intervalle de temps d’allocation automatique de la bande passante, l’utilisation moyenne maximale actuelle de la bande passante est comparée à la bande passante allouée pour le LSP. Si le LSP a besoin de plus de bande passante, tentez de configurer un nouveau chemin dans lequel la bande passante est égale à l’utilisation moyenne maximale actuelle. Si la tentative réussit, le trafic du LSP est acheminé via le nouveau chemin et l’ancien chemin est supprimé. En cas d’échec de la tentative, le LSP continue d’utiliser son chemin actuel.

REMARQUE :

Lors du calcul de la valeur de Max AvgBW (par rapport au LSP d’entrée), l’échantillon collecté lors de la fabrication avant rupture (MBB) est ignoré pour éviter des résultats inexacts. Le premier échantillon après un ajustement de la bande passante, ou après une modification de l’ID LSP (quel que soit le changement de chemin), est également ignoré.

Si vous avez configuré la protection des liens et des nœuds pour le LSP et que le trafic a été basculé vers le LSP de dérivation, la fonctionnalité d’allocation automatique de la bande passante continue de fonctionner et de prélever des échantillons de bande passante à partir du LSP de dérivation. Pour le premier cycle d’ajustement de la bande passante, l’utilisation moyenne maximale de la bande passante extraite du LSP protégé par la liaison et le nœud d’origine est utilisée pour resignaler le LSP de dérivation si davantage de bande passante est nécessaire. (La protection de liaison et de nud n’est pas prise en charge sur les commutateurs QFX Series.)

Si vous avez configuré le reroutage rapide pour le LSP, vous ne pourrez peut-être pas utiliser cette fonctionnalité pour ajuster la bande passante. Étant donné que les LSP utilisent un style de réservation de filtre fixe (FF), lorsqu’un nouveau chemin est signalé, la bande passante peut être comptée deux fois. Le double comptage peut empêcher un LSP à reroutage rapide d’ajuster sa bande passante lorsque l’allocation automatique de la bande passante est activée. (Le reroutage rapide n’est pas pris en charge sur les commutateurs QFX Series.)

Pour configurer l’allocation automatique de la bande passante, suivez les étapes décrites dans les sections suivantes :

REMARQUE :

Sur les commutateurs QFX10000, vous ne pouvez configurer l’allocation automatique de la bande passante qu’au niveau de la edit protocols mpls hiérarchie. Les systèmes logiques ne sont pas pris en charge.

Configuration des ajustements optimisés de la bande passante automatique pour les LSP MPLS

La fonctionnalité de bande passante automatique permet aux LSP RSVP-TE, soit directement configurés, soit créés automatiquement à l’aide du maillage automatique, de se redimensionner en fonction du débit de trafic. Le taux de trafic transporté sur chaque LSP est mesuré en recueillant périodiquement des échantillons du taux de trafic. La fréquence de collecte des statistiques de trafic est contrôlée par l’instruction de set protocols mpls statistics interval configuration. Le redimensionnement des LSP est appelé ajustement et la fréquence des ajustements est contrôlée par l’instruction adjust-interval . La valeur minimale configurable de adjust-interval est d’une seconde.

À compter de Junos OS version 20.4R1, la durée minimale adjust-interval d’un auto-bandwidth ajustement est réduite à 150 secondes si les instructions or adjust-threshold-underflow-limit dépassent les adjust-threshold-overflow-limit valeurs de seuil de dépassement ou de sous-débit configurées.

Cependant, le minimum adjust-interval pour un ajustement est de auto-bandwidth 300 secondes si aucun échantillon de débordement ou de sous-débordement n’est détecté.

Dans les versions antérieures à Junos OS version 20.4R1, le est de 300 secondes dans des conditions de dépassement ou de adjust-interval sous-débit.

Avec la mise en œuvre de l’optimisation de l’ajustement automatique de la bande passante, la auto-bandwidth diminution de la bande passante du LSP diminue plus rapidement. Le routeur de périphérie d’étiquettes d’entrée (LER) peut être redimensionné en 150 secondes grâce à la réduction de adjust-threshold-overflow-limit, à condition que le démontage d’une ancienne instance LSP après la création avant rupture (MBB) soit effectué dans les 150 secondes.

Les conditions requises pour l’optimisation automatique de la bande passante sont les suivantes :

  • Reduce the probability of LSP route change (Réduire la probabilité de changement de route LSP) : permet de réduire la probabilité de changement de route LSP lorsqu’un ajustement automatique de la bande passante se produit.

  • Réduire la probabilité de réacheminement du LSP : il s’agit de réduire la probabilité du réacheminement du LSP en raison des LSP de priorité plus élevée qui exigent la même ressource.

Afin de répondre à ces exigences, l’optimisation des ajustements automatiques de la bande passante prend en charge les éléments suivants :

  1. In-place LSP Bandwidth Update: permet au routeur de périphérie (LER) d’étiquettes d’entrée de réutiliser l’ID LSP lors d’une modification de la bande passante sur un LSP intradomaine.

    REMARQUE :

    La mise à jour de la bande passante d’un LSP sur place ne s’applique pas à un LSP inter-domaine.

    Dans certains scénarios, le tronçon suivant de la route LSP transporte la bande passante du LSP directement ou indirectement. Même si la mise à jour de la bande passante LSP sur place est prise en charge dans ces scénarios, l’amélioration des performances par rapport à la fonctionnalité est limitée en raison de la modification de la route LSP. C’est-à-dire en raison de la modification de la table de routage inet.3 après l’auto-bande passante (tunnel MPLS). Par exemple, l’amélioration des performances est limitée lorsque vous configurez l’une ou l’autre des instructions ou les deux :

    • auto-policing configuré sous MPLS.

    • L’option bandwidth sous l’instruction load-balance configurée sous RSVP.

    REMARQUE :

    La mise à jour de la bande passante LSP sur place via la réutilisation de LSP-ID échoue et le LER entrant déclenche immédiatement MBB avec un nouvel ID LSP si :

    • no-cspf est configuré pour le LSP.

    • Le LSP est contrôlé par le Path Computation Element (PCE).

    • Le minuteur d’optimisation LSP se déclenche.

    • clear mpls lsp optimize-aggressive commande est exécutée.

  2. Per-priority Subscription—Afin d’utiliser les ressources réseau plus efficacement, l’abonnement par priorité vous permet de configurer un pourcentage d’abonnement RSVP plus faible pour les LSP de priorité inférieure et un pourcentage d’abonnement RSVP plus élevé pour les LSP de priorité plus élevée.

    Par exemple, au lieu de définir un pourcentage d’abonnement RSVP à 90 % pour les prestataires de services linguistiques de toutes les priorités, vous pouvez configurer un pourcentage d’abonnement à réponses inférieur (disons 75 %) pour les prestataires de services linguistiques de priorités inférieures

REMARQUE :

L’abonnement par priorité n’interagit pas avec les aspects techniques du trafic (TE) sensibles aux services différenciés (DiffServ). Les services différenciés (DiffServ) offrent un partage statistique et plus flexible de la bande passante de la liaison TE qu’un abonnement par priorité.

To Configure In-place LSP Auto-bandwidth Resizing:

  1. Configurez l’interface de l’appareil pour activer MPLS.
  2. Configurez le protocole MPLS sur l’interface.
  3. Configurez MPLS et les LSP, et configurez la protection des liens pour le LSP.
  4. Configurez in-place-bandwidth-update le LSP pour qu’il active le redimensionnement automatique du LSP de la bande passante.
  5. Entrez commit à partir du mode de configuration.

Verification

À partir du mode configuration, confirmez votre configuration en entrant les commandes . show protocols show interfaces Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

To Configure Per-priority Subscription:

  1. Configurez le protocole RSVP sur l’interface.

  2. Configurez la valeur d’abonnement à la bande passante pour l’interface. Il peut s’agir d’une valeur comprise entre 0 et 65 000 %. La valeur d’abonnement par défaut est de 100 %.

  3. Configurez la priorité d’abonnement sur l’interface.

  4. Configurez le pourcentage d’abonnement pour la priorité.

  5. Entrez commit à partir du mode de configuration.

Verification

À partir du mode configuration, confirmez votre configuration en entrant les commandes . show protocols show interfaces Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Configuration de la création de rapports sur les statistiques d’allocation automatique de la bande passante pour les prestataires de services linguistiques

L’allocation automatique de la bande passante permet à un tunnel MPLS d’ajuster automatiquement son allocation de bande passante en fonction du volume de trafic circulant dans le tunnel. Vous pouvez configurer l’appareil pour qu’il collecte des statistiques relatives à l’allocation automatique de la bande passante en procédant comme suit :

  1. Pour collecter des statistiques relatives à l’allocation automatique de la bande passante, configurez l’option de l’instruction auto-bandwidthstatistics au niveau de la [edit protocols mpls] hiérarchie. Ces paramètres s’appliquent à tous les LSP configurés sur le routeur sur lequel vous avez également configuré l’instruction auto-bandwidth au niveau de la [edit protocols mpls label-switched-path label-switched-path-name] hiérarchie.
  2. Spécifiez le filename pour les fichiers utilisés pour stocker la sortie de l’opération de traçage MPLS à l’aide de l’option file . Tous les fichiers sont placés dans le répertoire /var/log. Nous vous recommandons de placer la sortie de traçage MPLS dans le fichier mpls-log.
  3. Spécifiez le nombre maximal de fichiers de trace à l’aide de l’option files number . Lorsqu’un fichier de trace nommé trace-file atteint sa taille maximale, il est renommé trace-file.0, puis , et trace-file.1 ainsi de suite, jusqu’à ce que le nombre maximal de fichiers de trace soit atteint. Ensuite, le fichier de trace le plus ancien est écrasé.
  4. Spécifiez l’intervalle de calcul de l’utilisation moyenne de la bande passante en configurant une durée en secondes à l’aide de l’option interval . Vous pouvez également définir l’intervalle d’ajustement sur un LSP spécifique en configurant l’option interval au niveau de la [edit protocols mpls label-switch-path label-switched-path-name statistics] hiérarchie.
    REMARQUE :

    Pour éviter toute resignalisation inutile des LSP, il est préférable de configurer un intervalle d’ajustement LSP au moins trois fois plus long que l’intervalle des statistiques automatiques de bande passante MPLS. Par exemple, si vous configurez une valeur de 30 secondes pour l’intervalle de statistiques automatiques de bande passante MPLS ( instruction au niveau de la hiérarchie), vous devez configurer une valeur d’au moins 90 secondes pour l’intervalle d’ajustement LSP (intervaladjust-interval instruction au niveau de la [edit protocols mpls statistics][edit protocols mpls label-switched-path label-switched-path-name auto-bandwidth] hiérarchie).

  5. Pour tracer l’allocation automatique de la bande passante, incluez l’instruction for the MPLS traceoptions au niveau de autobw-state flag la [edit protocols mpls] hiérarchie.

    La configuration suivante active les traceoptions MPLS pour l’allocation automatique de la bande passante. Les enregistrements de trace sont stockés dans un fichier appelé auto-band-trace (le nom du fichier est configurable par l’utilisateur) :

  6. À l’aide de la commande, vous pouvez afficher le fichier de statistiques d’allocation automatique de la bande passante généré lorsque vous configurez l’instruction show logauto-bande passante (Statistiques MPLS). L’exemple suivant montre un exemple de sortie de fichier journal à partir d’un fichier de statistiques MPLS nommé sur un routeur configuré avec un LSP nommé auto-band-statsE-D. Le fichier journal indique que LSP E-D fonctionne initialement au-delà de sa limite de bande passante réservée. Avant Oct 30 17:14:57, le routeur déclenchait un ajustement automatique de la bande passante (vous pouvez voir deux sessions d’un LSP subir un ajustement automatique de la bande passante). En Oct 30 17:16:57, le LSP a été rétabli à une bande passante plus élevée et est maintenant affiché en utilisant moins de 100 % de sa Reserved Bw bande passante réservée.
  7. Exécutez la commande show mpls lsp autobandwidth pour afficher les informations actuelles sur l’allocation automatique de la bande passante. Voici un exemple de sortie de la show mpls lsp autobandwidth commande prise à peu près en même temps que le fichier journal indiqué précédemment :
  8. Exécutez la file show commande pour afficher le fichier de trace MPLS. Vous devez spécifier l’emplacement et le nom du fichier (le fichier se trouve dans /var/log/. L’exemple suivant montre que la sortie du fichier de trace est extraite d’un fichier de trace MPLS nommé sur un routeur configuré avec un LSP nommé auto-band-trace.0.gzE-D. Le fichier de trace indique que LSP E-D fonctionne initialement au-delà de sa limite de bande passante réservée. À Oct 30 17:15:26, le routeur déclenche un ajustement automatique de la bande passante (vous pouvez voir deux sessions d’un LSP subir un ajustement automatique de la bande passante). En Oct 30 17:15:57, le LSP a été rétabli à une bande passante plus élevée et est maintenant affiché en utilisant moins de 100 % de sa Reserved Bw bande passante réservée.

Configuration d’un LSP sur les AS

Vous pouvez configurer un LSP pour qu’il traverse plusieurs zones d’un réseau en incluant l’instruction inter-domain dans la configuration du LSP. Cette instruction permet au routeur de rechercher des routes dans la base de données IGP. Vous devez configurer cette instruction sur les routeurs qui peuvent ne pas être en mesure de localiser un chemin à l’aide de CSPF intra-domaine (en consultant la base de données d’ingénierie du trafic (TED)). Lorsque vous configurez des LSP inter-zones, l’instruction inter-domain est obligatoire.

Avant de commencer :

  • Configurez les interfaces de l’appareil avec la famille MPLS.

  • Configurez l’ID du routeur de l’appareil et le numéro du système autonome.

  • Activez MPLS et RSVP sur le routeur et les interfaces de transit.

  • Configurez votre IGP pour prendre en charge les aspects techniques du trafic.

  • Configurez un LSP à partir du routeur d’entrée vers le routeur de sortie.

Pour configurer un LSP sur plusieurs AS sur le routeur à commutation d’étiquettes (LER) d’entrée :

  1. Activez MPLS sur toutes les interfaces (à l’exception de l’interface de gestion).
  2. Activez RSVP sur toutes les interfaces (à l’exception de l’interface de gestion).
  3. Configurez le LSP inter-zone.
  4. Vérifiez et validez la configuration.

Annonce d’amortissement des modifications de l’état LSP

Lorsqu’un LSP passe de « actif » à « inactif », ou de « bas » à « actif », cette transition prend effet immédiatement dans le logiciel et le matériel du routeur. Toutefois, lorsque vous publiez des LSP dans IS-IS et OSPF, vous souhaiterez peut-être atténuer les transitions LSP, de sorte de ne pas annoncer la transition avant qu’une certaine période de temps ne se soit écoulée (connue sous le nom de temps d’attente). Dans ce cas, si le LSP passe de haut en bas, il n’est pas annoncé comme étant en panne tant qu’il n’est pas resté en panne pendant la période de retenue. Les transitions ascendantes sont immédiatement annoncées dans IS-IS et OSPF. Notez que l’amortissement LSP n’affecte que les annonces IS-IS et OSPF du LSP ; les autres logiciels et matériels de routage réagissent immédiatement aux transitions LSP.

Pour amortir les transitions LSP, incluez l’instruction advertisement-hold-time suivante :

seconds peut prendre une valeur comprise entre 0 et 65 535 secondes. La valeur par défaut est de 5 secondes.

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

  • [edit protocols mpls]

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

Configuration des LSP bidirectionnels coroutés

Un LSP de paquet bidirectionnel corouté est une combinaison de deux LSP partageant le même chemin entre une paire de nuds entrants et sortants, comme illustré à Figure 2la . Il est établi à l’aide des extensions GMPLS de RSVP-TE. Ce type de LSP peut être utilisé pour transporter n’importe quel type de trafic MPLS standard, y compris les VPN de couche 2, les circuits de couche 2 et les VPN de couche 3. Vous pouvez configurer une seule session BFD pour le LSP bidirectionnel (vous n’avez pas besoin de configurer une session BFD pour chaque LSP dans chaque direction). Vous pouvez également configurer un seul LSP bidirectionnel de secours pour fournir une sauvegarde au LSP bidirectionnel principal. Les LSP bidirectionnels coroutés sont pris en charge à la fois pour l’avant-dernier saut popping (PHP) et l’ultimate hop popping (UHP).

La haute disponibilité est disponible pour les LSP bidirectionnels. Vous pouvez activer un redémarrage progressif et un routage actif ininterrompu. Le redémarrage progressif et le routage actif ininterrompu sont pris en charge lorsque le routeur qui redémarre est le routeur d’entrée, de sortie ou de transit du LSP bidirectionnel.

Figure 2 : LSP bidirectionnel coroutéLSP bidirectionnel corouté

Pour configurer un LSP bidirectionnel corouté :

  1. En mode configuration, configurez le routeur entrant pour le LSP et incluez l’instruction corouted-bidirectional pour spécifier que le LSP doit être établi en tant que LSP bidirectionnel corouté.

    Le chemin est calculé à l’aide de CSPF et initié à l’aide de la signalisation RSVP (tout comme un LSP unidirectionnel avec signal RSVP). Le chemin d’accès au routeur de sortie et le chemin inverse du routeur de sortie sont créés lorsque cette configuration est validée.

  2. (Facultatif) Pour un chemin inverse, configurez un LSP sur le routeur de sortie et incluez l’instruction corouted-bidirectional-passive pour associer le LSP à un autre LSP.

    Aucun calcul ou signalisation de chemin n’est utilisé pour ce LSP, car il repose sur le calcul de chemin et la signalisation fournis par le LSP d’entrée. Vous ne pouvez pas configurer à la fois l’instruction et l’instruction corouted-bidirectionalcorouted-bidirectional-passive sur le même LSP.

    Cette instruction facilite également le débogage des LSP bidirectionnels coroutés. Si vous configurez l’instruction corouted-bidirectional-passive (encore une fois, sur le routeur de sortie), vous pouvez émettre ping mpls lsp-end-pointles commandes , , ping mpls ldpping mpls rsvp, traceroute mpls ldpet traceroute mpls rsvp pour tester le LSP bidirectionnel corouté à partir du routeur de sortie.

  3. Utilisez les commandes et show mpls lsp extensive the pour show rsvp session extensive afficher des informations sur le LSP bidirectionnel.

    Ce qui suit montre la sortie de la commande lorsqu’elle show rsvp session extensive est exécutée sur un routeur entrant avec un LSP bidirectionnel configuré :

Configuration de l’étiquette d’entropie pour les LSP

L’insertion d’étiquettes d’entropie pour un LSP permet aux routeurs de transit d’équilibrer la charge du trafic MPLS sur des chemins ECMP ou des groupes d’agrégation de liens en utilisant uniquement la pile d’étiquettes MPLS comme entrée de hachage sans avoir à recourir à une inspection approfondie des paquets. L’inspection approfondie des paquets nécessite une plus grande puissance de traitement du routeur et les capacités d’inspection approfondie des paquets diffèrent d’un routeur à l’autre.

Pour configurer l’étiquette d’entropie d’un LSP, procédez comme suit :

  1. Sur le routeur entrant, incluez l’instruction entropy-label au niveau hiérarchique ou hiérarchique [edit protocols mpls labeled-switched-path labeled-switched-path-name][edit protocols mpls static-labeled-switched-path labeled-switched-path-name ingress] . L’étiquette d’entropie est ajoutée à la pile d’étiquettes MPLS et peut être traitée dans le plan de transfert.
    REMARQUE :

    Cela ne s’applique qu’aux RSVP et aux LSP statiques.

  2. Sur le routeur entrant, vous pouvez configurer une stratégie d’entrée pour les LSP signalés par LDP :

    Configurez la stratégie d’entrée au niveau de la [edit policy-options] hiérarchie :

    L’exemple suivant illustre une stratégie d’entrée d’étiquette d’entropie.

  3. (Facultatif) Par défaut, les routeurs qui prennent en charge l’envoi et l’éclatement d’étiquettes d’entropie sont configurés avec l’instruction au niveau de la load-balance-label-capability[edit forwarding-options] hiérarchie pour signaler les étiquettes par LSP. Si le routeur homologue n’est pas équipé pour gérer les étiquettes d’équilibrage de charge, vous pouvez empêcher le routeur PE (Provider Edge) de signaler la capacité d’étiquette d’entropie en configurant l’instruction no-load-balance-label-capability au niveau de la [edit forwarding-options] hiérarchie.

Les routeurs de transit ne nécessitent aucune configuration. La présence de l’étiquette d’entropie indique au routeur de transit d’équilibrer la charge en se basant uniquement sur la pile d’étiquettes MPLS.

Les routeurs d’avant-dernier saut font apparaître l’étiquette d’entropie par défaut.

Example: Configuring an Entropy Label for a BGP Labeled Unicast LSP

This example shows how to configure an entropy label for a BGP labeled unicast to achieve end-to-end load balancing using entropy labels. When an IP packet has multiple paths to reach its destination, Junos OS uses certain fields of the packet headers to hash the packet to a deterministic path. This requires an entropy label, a special load-balancing label that can carry the flow information. LSRs in the core simply use the entropy label as the key to hash the packet to the correct path. An entropy label can be any label value between 16 to 1048575 (regular 20-bit label range). Since this range overlaps with the existing regular label range, a special label called entropy label indicator (ELI) is inserted before the entropy label. ELI is a special label assigned by IANA with the value of 7.

BGP labeled unicasts generally concatenate RSVP or LDP LSPs across multiple IGP areas or multiple autonomous systems. RSVP or LDP entropy labels are popped at the penultimate hop node, together with the RSVP or LDP label. This feature enables the use of entropy labels at the stitching points to bridge the gap between the penultimate hop node and the stitching point, in order to achieve end-to-end entropy label load balancing for BGP traffic.

Requirements

This example uses the following hardware and software components:

  • Seven MX Series routers with MPCs

  • Junos OS Release 15.1 or later running on all the devices

    • Revalidated using Junos OS Relese 22.4

Before you configure an entropy label for BGP labeled unicast, make sure you:

  1. Configure the device interfaces.

  2. Configure OSPF or any other IGP protocol.

  3. Configure BGP.

  4. Configure RSVP.

  5. Configure MPLS.

Overview

When BGP labeled unicasts concatenate RSVP or LDP LSPs across multiple IGP areas or multiple autonomous systems, RSVP or LDP entropy labels are popped at the penultimate hop node, together with the RSVP or LDP label. However, there are no entropy labels at the stitching points, that is, the routers between two areas. Therefore, the routers at the stitching points used the BGP labels to forward packets.

Beginning with Junos OS Release 15.1, you can configure an entropy label for BGP labeled unicast to achieve end-to-end entropy label load balancing. This feature enables the use of an entropy label at the stitching points in order to achieve end-to-end entropy label load balancing for BGP traffic. Junos OS allows the insertion of entropy labels at the BGP labeled unicast LSP ingress.

By default, routers that support entropy labels are configured with the load-balance-label-capability statement at the [edit forwarding-options] hierarchy level to signal the labels on a per-LSP basis. If the peer router is not equipped to handle load-balancing labels, you can prevent the signaling of entropy label capability by configuring the no-load-balance-label-capability at the [edit forwarding-options] hierarchy level.

Note :

You can explicitly disable advertising entropy label capability at egress for routes specified in the policy with the no-entropy-label-capability option at the [edit policy-options policy-statement policy name then] hierarchy level.

Topology

In Figure 3 , Router PE1 is the ingress router and Router PE2 is the egress router. Routers P1 and P2 are the transit routers. Router ABR is the area bridge router between Area 0 and Area 1. Two LSPs are configured on the ABR to PE2 for load balancing the traffic. Entropy label capability for BGP labeled unicast is enabled on the ingress Router PE1. Host 1 is connected to P1 for packet captures so that we can show the entropy label.

Figure 3 : Configuring an Entropy Label for BGP Labeled UnicastConfiguring an Entropy Label for BGP Labeled Unicast

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Router CE1

Router PE1

Router P1

Router ABR

Router P2

Router PE2

Router CE2

Configuring Router PE1

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router PE1:

Note :

Repeat this procedure for Router PE2 after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure the physical interfaces. Ensure to configure family mpls on the core facing interface.

  2. Configure the loopback interfaces. The secondary loopback is optional and is applied under the routing instance in a later step.

  3. Configure the router ID and the autonomous system number.

  4. Configure the OSPF protocol.

  5. Configure the RSVP protocol.

  6. Configure the MPLS protocol and an LSP towards the ABR. Include the entropy-label option to add the entropy label to the MPLS label stack.

  7. Configure IBGP using family inet labeled-unicast for the ABR peering and family inet-vpn for the PE2 peering. Enable entropy label capability for BGP labeled unicast.

  8. Define a policy to export BGP VPN routes into OSPF. The policy is applied under OSPF in the routing instance.

  9. Define a load balancing policy and apply it under the routing-options forwarding-table. PE1 only has one path in the example therefore this step is not needed, but for this example we are applying the same load balancing policy on all devices.

  10. Configure the Layer 3 VPN routing instance.

  11. Assign the interfaces to the routing instance.

  12. Configure the route distinguisher for the routing instance.

  13. Configure a VPN routing and forwarding (VRF) target for the routing instance.

  14. Configure the protocol OSPF under the routing instance and apply the previously configured bgp-to-ospf policy.

Configuring Router P1

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router P1:

Note :

Repeat this procedure for Router P2 after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure the physical interfaces.

  2. Configure the loopback interface.

  3. Configure the router ID.

  4. Configure the OSPF protocol.

  5. Configure the RSVP protocol.

  6. Configure the MPLS protocol.

Configuring Router ABR

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router ABR:

  1. Configure the physical interfaces.

  2. Configure the loopback interface.

  3. Configure MPLS labels that the router uses for hashing the packets to its destination for load balancing.

  4. Configure the router ID and the autonomous system number.

  5. Configure the OSPF protocol.

  6. Configure the RSVP protocol.

  7. Configure the MPLS protocol and specify the LSPs towards PE1 and PE2. Two LSPs are created towards PE2 for the purpose of load balancing traffic to show different LSPs and interfaces are used.

  8. Configure IBGP to both PE1 and PE2 using family inet labeled-unicast. Apply the policy to advertise the inet.3 loopback route from both PE1 and PE2. We show the policy in the next step.

  9. Define a policy to match on the loopback addresses for PE1 and PE2.

  10. Define a policy for load balancing and apply it under the routing-options forwarding-table.

(Optional) Port-Mirroring Configuration

To see the entropy label that is applied you can capture the traffic. In this example a filter is applied on the PE1 facing interface on P1 to capture the CE1 to CE2 traffic. The traffic is sent to Host 1 for viewing. There are different ways to capture traffic than what we use in this example. For more information see Comprendre la mise en miroir de ports et les analyseurs.

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router P1:

  1. Configure the interfaces. In this example we are putting the interface connected to Host1 in a bridge domain and creating an IRB interface for verifying connectivity to Host1.

  2. Configure the bridge domain.

  3. Configure a filter to capture the traffic. For this example we are capturing all traffic.

  4. Apply the filter to the PE1 facing interface.

  5. Configure the port mirroring options. For this example we are mirroring all traffic and sending it to Host1 connected to interface ge-0/0/4.

Verification

Confirm that the configuration is working properly.

Verifying That the Entropy Label Capability Is Being Advertised

Purpose

Verify that the entropy label capability path attribute is being advertised from the ABR to PE1 for the route to PE2.

Action

From operational mode, run the show route advertising-protocol bgp 10.1.255.2 detail command on Router ABR.

Meaning

The output shows that the host PE2 with the IP address of 10.1.255.6 has the entropy label capability and the route label that is used. The host is advertising the entropy label capability to its BGP neighbors.

Verifying That Router PE1 Receives the Entropy Label Advertisement

Purpose

Verify that Router PE1 receives the entropy label advertisement for Router PE2.

Action

From operational mode, run the show route protocol bgp 10.1.255.6 extensive command on Router PE1.

Meaning

Router PE1 receives the entropy label capability advertisement from its BGP neighbor.

Verifying ECMP at the ABR to PE2

Purpose

Verify equal-cost multipath (ECMP) to PE2.

Action

From operational mode, run the show route table mpls.0 and show route forwarding-table label <label>commands on Router ABR.

Meaning

The output shows an ECMP for the label used for the BGP labeled unicast route.

Show Routes to CE2 on PE1

Purpose

Verify the routes to CE2.

Action

From operational mode, run the show route table VPN-l3vpn.inet.0 172.16.255.7 extensive and show route table VPN-l3vpn.inet.0 192.168.255.7 extensivecommands on Router PE1.

Meaning

The output shows the same labels are used for both routes.

Ping CE2 from CE1

Purpose

Verify connectivity and to use for verifying load balancing.

Action

From operational mode, run the ping 172.16.255.7 source 172.16.12.1 rapid count 100 and ping 192.168.255.7 source 192.168.255.1 rapid count 200commands on Router PE1.

Meaning

The output shows pings are successful.

Verify Load Balancing

Purpose

Verify load balancing.

Action

From operational mode, run the show mpls lsp ingress statistics command on the ABR.

Meaning

The output shows the first ping from the previous command used LSP abr-pe2-2 and the second ping used LSP abr-pe2.

Verify the Entropy Label

Purpose

Verify the entropy label is different between the pings that were used.

Action

On Host 1, run the tcpdump -i eth1 -n.

Meaning

The output shows the different value for the entropy label for the two different ping commands.

Configuration de l’Ultimate-Hop Popping pour les LSP

Par défaut, les LSP signalés par RSVP utilisent l’popping par avant-dernier saut (PHP). Figure 4 illustre un LSP popping par avant-dernier saut entre le routeur PE1 et le routeur PE2. Le routeur CE1 transmet un paquet à son tronçon suivant (routeur PE1), qui est également l’entrée LSP. Le routeur PE1 appuie l’étiquette 1 sur le paquet et transmet le paquet étiqueté au routeur P1. Le routeur P1 effectue l’opération d’échange d’étiquettes MPLS standard, en remplaçant l’étiquette 1 par l’étiquette 2, puis transmet le paquet au routeur P2. Étant donné que le routeur P2 est l’avant-dernier saut du LSP vers le routeur PE2, il fait d’abord sauter l’étiquette, puis transfère le paquet au routeur PE2. Lorsque le routeur PE2 le reçoit, le paquet peut avoir une étiquette de service, une étiquette explicitement nulle, ou simplement un paquet IP ou VPLS simple. Le routeur PE2 transfère le paquet sans étiquette au routeur CE2.

Figure 4 : Saut d’avant-dernier saut pour un LSPSaut d’avant-dernier saut pour un LSP

Vous pouvez également configurer le popping par saut ultime (UHP) (comme illustré à Figure 5la ) pour les LSP signalés par RSVP. Certaines applications réseau peuvent exiger que les paquets arrivent au routeur de sortie (routeur PE2) avec une étiquette externe non nulle. Dans le cas d’un LSP d’extraction de saut ultime, l’avant-dernier routeur (entrée de routeur P2) effectue l’opération d’échange d’étiquettes MPLS standard (dans cet exemple, l’étiquette 2 pour l’étiquette 3) avant de transférer le paquet au routeur de sortie PE2 Figure 5. Le routeur PE2 retire l’étiquette extérieure et effectue une deuxième recherche de l’adresse du paquet pour déterminer la destination finale. Il transfère ensuite le paquet vers la destination appropriée (routeur CE2 ou routeur CE4).

Figure 5 : Ultimate Hop Popping pour un LSPUltimate Hop Popping pour un LSP

Les applications réseau suivantes nécessitent que vous configuriez des LSP UHP :

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

  • Circuits virtuels de protection de périphérie

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

  • LSP signalés par LDP

  • LSP statiques

  • LSP point à multipoint

  • CCC

  • traceroute Commande

Pour plus d’informations sur le comportement UHP, consultez Brouillon Internet draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, Comportement non-PHP et Mappage hors bande pour les LSP RSVP-TE.

Pour les LSP point à point avec RSVP, le comportement UHP est signalé à partir de l’entrée LSP. En fonction de la configuration du routeur entrant, RSVP peut signaler le LSP UHP avec l’indicateur non-PHP défini. Les messages RSVP PATH portent les deux indicateurs dans l’objet LSP-ATTRIBUTES. Lorsque le routeur de sortie reçoit le message PATH, il attribue une étiquette 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 de l’étiquette 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 cet itinéraire pointe vers la table de routage mpls.0, déclenchant une recherche d’étiquettes MPLS chaînée pour découvrir les étiquettes 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 chaînée et multifamiliale. Alternativement, l’itinéraire d’étiquette peut pointer vers une interface VT pour initier le transfert IP.

Si vous activez les LSP UHP, les applications MPLS telles que les VPN de couche 3, les VPLS, les VPN de couche 2 et les circuits de couche 2 peuvent utiliser les LSP UHP. Vous trouverez ci-dessous les avantages des LSP UHP sur les différents types d’applications MPLS :

  • VPN de couche 2 et circuits de couche 2 : un paquet arrive au routeur PE (sortie du LSP UHP) avec deux étiquettes. L’étiquette extérieure (S = 0) est l’étiquette UHP et l’étiquette intérieure (S = 1) est l’étiquette VC . Une recherche basée sur l’étiquette de transport génère un descripteur de table pour la table de routage mpls.0. Il existe une route supplémentaire dans la table de routage mpls.0 correspondant à l’étiquette interne. Une recherche basée sur l’étiquette interne génère le saut suivant du routeur CE.

  • VPN de couche 3 : un paquet arrive au routeur PE (sortie du LSP UHP) avec deux étiquettes. L’étiquette externe (S = 0) est l’étiquette UHP et l’étiquette intérieure est l’étiquette VPN (S = 1). Une recherche basée sur l’étiquette de transport génère le descripteur de table de la table de routage mpls.0. Il y a deux cas dans ce scénario. Par défaut, les VPN de couche 3 annoncent l’étiquette par saut suivant. Une recherche basée sur l’étiquette interne génère le saut suivant vers le routeur CE. Toutefois, si vous avez configuré l’instruction pour l’instance de routage VPN de couche 3, l’étiquettevrf-table-label LSI interne pointe vers la table de routage VRF. Une recherche IP est également effectuée pour la table de routage VRF.

    REMARQUE :

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

  • VPLS : un paquet arrive au routeur PE (sortie du LSP UHP) avec deux étiquettes. L’étiquette extérieure est l’étiquette de transport (S = 0) et l’étiquette intérieure est l’étiquette VPLS (S = 1). Une recherche basée sur l’étiquette de transport génère le descripteur de table de la table de routage mpls.0. Une recherche basée sur l’étiquette interne dans la table de routage mpls.0 génère l’interface de tunnel LSI de l’instance de routage VPLS si tunnel-services n’est pas configuré (ou si une interface VT n’est pas disponible). Les routeurs MX 3D Series prennent en charge la recherche chaînée et la recherche multifamiliale.

    REMARQUE :

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

  • IPv4 sur MPLS : un paquet arrive au routeur PE (sortie du LSP UHP) avec une étiquette (S=1). Une recherche basée sur cette étiquette renvoie une interface de tunnel VT. Une autre recherche IP est effectuée sur l’interface VT pour déterminer où transférer le paquet. Si la plate-forme de routage prend en charge les recherches multifamiliales et chaînées (par exemple, les routeurs MX 3D et les PTX Series Routeurs de transport de paquets), la recherche basée sur l’itinéraire d’étiquettes (S=1) pointe vers le table de routage inet.0.

  • IPv6 sur MPLS : pour la tunnelisation IPv6 sur MPLS, les routeurs PE s’annoncent mutuellement des routes IPv6 avec une valeur d’étiquette de 2. Il s’agit de l’étiquette NULL explicite pour IPv6. Par conséquent, les sauts suivants de transfert pour les routes IPv6 apprises à partir de routeurs PE distants envoient normalement deux étiquettes. L’étiquette intérieure est 2 (elle peut être différente si le routeur PE publicitaire provient d’un autre fournisseur) et l’étiquette du routeur est l’étiquette LSP. Les paquets arrivent au routeur PE (sortie du LSP UHP) avec deux étiquettes. L’étiquette externe est l’étiquette de transport (S=0) et l’étiquette interne est l’étiquette IPv6 explicit-null (étiquette 2). La recherche basée sur l’étiquette interne dans la table de routage mpls.0 redirige vers la table de routage mpls.0. Sur les routeurs MX 3D Series, l’étiquette interne (étiquette 2) est supprimée et une recherche IPv6 est effectuée à l’aide de la table de routage inet6.0.

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

Les instructions suivantes activent l’apparition de sauts ultimes pour un LSP. Vous pouvez activer cette fonctionnalité sur un LSP spécifique ou sur tous les LSP entrants configurés sur le routeur. Configurez ces instructions sur le routeur à l’entrée LSP.

  1. Pour activer l’apparition de sauts ultimes, incluez l’instruction ultimate-hop-popping suivante :

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

    REMARQUE :

    Lorsque vous activez l’inpopping par saut ultime, RSVP tente de resignaler les LSP existants en tant que LSP d’extraction par saut ultime, de manière à faire avant de rompre. Si un routeur de sortie ne prend pas en charge l’apparition de sauts ultimes, le LSP existant est détruit (RSVP envoie un message PathTear le long du chemin d’un LSP, supprimant l’état de chemin et l’état de réservation dépendante et libérant les ressources réseau associées).

    Si vous désactivez l’apparition d’un saut ultime, RSVP resignale les LSP existants en tant que LSP d’éclatement d’avant-dernier saut de manière à faire avant de rompre.

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

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

Configuration des LSP Explicit-Path

Si vous désactivez le calcul du chemin de commutation d’étiquettes (LSP) à chemin contraint, comme décrit dans Désactivation du calcul du LSP à chemin contraint, vous pouvez configurer les LSP manuellement ou les autoriser à suivre le chemin IGP.

Lorsque des LSP à chemin explicite sont configurés, ils sont établis le long du chemin que vous avez spécifié. Si le chemin n’est pas réalisable d’un point de vue topologique, soit parce que le réseau est partitionné, soit parce que les ressources disponibles sont insuffisantes le long de certaines parties du chemin, le LSP échoue. Aucun chemin alternatif ne peut être utilisé. Si l’installation réussit, le LSP reste indéfiniment sur le chemin défini.

Pour configurer un LSP à chemin explicite, procédez comme suit :

  1. Configurez les informations de chemin d’accès dans un chemin nommé, comme décrit dans la section Création de chemins nommés. Pour configurer les informations complètes sur le chemin, spécifiez chaque saut de routeur entre les routeurs d’entrée et de sortie, de préférence à l’aide de l’attribut strict . Pour configurer des informations de chemin incomplètes, spécifiez uniquement un sous-ensemble de sauts de routeur, en utilisant l’attribut loose aux endroits où le chemin est incomplet.

    Pour les chemins incomplets, les routeurs MPLS complètent le chemin en interrogeant la table de routage locale. Cette requête est effectuée saut par saut, et chaque routeur ne peut trouver que suffisamment d’informations pour atteindre le prochain saut explicite. Il peut être nécessaire de traverser un certain nombre de routeurs pour atteindre le prochain saut explicite (lâche).

    La configuration d’informations de chemin incomplètes crée des parties du chemin qui dépendent de la table de routage actuelle, et cette partie du chemin peut être redirigée elle-même à mesure que la topologie change. Par conséquent, un LSP de chemin explicite qui contient des informations de chemin d’accès incomplètes n’est pas complètement corrigé. Ces types de LSP n’ont qu’une capacité limitée à se réparer et ont tendance à créer des boucles ou des battements en fonction du contenu de la table de routage locale.

  2. Pour configurer le LSP et le faire pointer vers le chemin nommé, utilisez l’instruction primary ou secondary , comme décrit dans Configuration des LSP principaux et secondaires.

  3. Désactivez le calcul du LSP à chemin contraint en incluant l’instruction dans le LSP ou dans le cadre d’une no-cspfprimary instruction or secondary . Pour plus d’informations, consultez Désactivation du calcul LSP à chemin contraint.

  4. Configurez toutes les autres propriétés LSP.

REMARQUE :

Lors de la définition d’un LSP de chemin contraint à l’aide de plusieurs sauts stricts appartenant au nœud de sortie, le premier saut strict doit être défini pour correspondre à l’adresse IP attribuée au nœud de sortie sur l’interface qui reçoit le message RSVP Path. Si le message RSVP Path entrant arrive sur une interface avec une adresse IP différente, le LSP est rejeté.

Avant Junos OS 20.3X75-D20 ou 22.2R1, tout saut strict supplémentaire après le saut strict correspondant à l’adresse IP de l’interface qui reçoit le message RSVP Path doit correspondre à une adresse de bouclage attribuée au nud de sortie. Dans les versions ultérieures de Junos, ce comportement est modifié pour permettre un saut strict supplémentaire qui correspond à une adresse IP attribuée à n’importe quelle interface sur le nud de sortie

L’utilisation de LSP à chemin explicite présente les inconvénients suivants :

  • Des efforts de configuration supplémentaires sont nécessaires.

  • Les informations de chemin configurées ne peuvent pas prendre en compte la réservation dynamique de la bande passante réseau, de sorte que les LSP ont tendance à échouer lorsque les ressources s’épuisent.

  • Lorsqu’un LSP explicite échoue, vous devrez peut-être le réparer manuellement.

En raison de ces limitations, nous vous recommandons d’utiliser les LSP à chemin explicite uniquement dans des situations contrôlées, par exemple pour appliquer une stratégie de placement LSP optimisée résultant de calculs avec un progiciel de simulation hors ligne.

Exemple : Configuration d’un LSP Explicit-Path

Sur le routeur entrant, créez un LSP à chemin explicite et spécifiez les routeurs de transit entre les routeurs d’entrée et de sortie. Dans cette configuration, aucun calcul de chemin contraint n’est effectué. Pour le chemin principal, tous les sauts intermédiaires sont strictement spécifiés afin que son itinéraire ne puisse pas changer. Le chemin secondaire doit d’abord passer par le routeur 14.1.1.1, puis emprunter le chemin disponible pour atteindre la destination. Le chemin restant emprunté par le chemin secondaire est généralement le chemin le plus court calculé par l’IGP.

REMARQUE :

Lors de la définition d’un LSP de chemin contraint à l’aide de plusieurs sauts stricts appartenant au nœud de sortie, le premier saut strict doit être défini pour correspondre à l’adresse IP attribuée au nœud de sortie sur l’interface qui reçoit le message RSVP Path. Si le message RSVP Path entrant arrive sur une interface avec une adresse IP différente, le LSP est rejeté.

Avant Junos OS 20.3X75-D20 ou 22.2R1, tout saut strict supplémentaire après le saut strict correspondant à l’adresse IP de l’interface qui reçoit le message RSVP Path doit correspondre à une adresse de bouclage attribuée au nud de sortie. Dans les versions ultérieures de Junos, ce comportement est modifié pour permettre un saut strict supplémentaire qui correspond à une adresse IP attribuée à n’importe quelle interface sur le nud de sortie

Présentation du surabonnement de bande passante LSP

Les LSP sont établis avec des réservations de bande passante configurées pour la quantité maximale de trafic que vous prévoyez de traverser le LSP. Tous les prestataires de services linguistiques n’acheminent pas le volume maximal de trafic sur leurs liens à tout moment. Par exemple, même si la bande passante de la liaison A a été entièrement réservée, il se peut que la bande passante réelle soit encore disponible, mais qu’elle ne soit pas utilisée. Cet excédent de bande passante peut être utilisé en permettant à d’autres LSP d’utiliser également la liaison A, en surabonnant la liaison. Vous pouvez surabonner la bande passante configurée pour les types de classes individuels ou spécifier une valeur unique pour tous les types de classes à l’aide d’une interface.

Vous pouvez utiliser le surabonnement pour tirer parti de la nature statistique des modèles de trafic et pour permettre une utilisation plus élevée des liaisons.

Les exemples suivants décrivent comment vous pouvez utiliser le surabonnement et le sous-abonnement de bande passante :

  • Utilisez le surabonnement pour les types de cours où les pics de trafic ne coïncident pas dans le temps.

  • Utilisez la sursursouscription de types de classe transportant un trafic best-effort. Vous prenez le risque de retarder ou d’interrompre temporairement le trafic en échange d’une meilleure utilisation des ressources réseau.

  • Attribuez différents degrés de surabonnement ou de sous-abonnement de trafic pour les différents types de classes. Par exemple, vous configurez l’abonnement pour les classes de trafic comme suit :

    • Meilleurs efforts—ct0 1000

    • Voix—ct3 1

Lorsque vous sous-abonnez un type de cours pour un LSP multiclasse, la demande totale de toutes les sessions RSVP est toujours inférieure à la capacité réelle du type de classe. Vous pouvez utiliser le sous-abonnement pour limiter l’utilisation d’un type de classe.

Le calcul du surabonnement de bande passante s’effectue uniquement sur le routeur local. Étant donné qu’aucune signalisation ou autre interaction n’est requise de la part des autres routeurs du réseau, la fonctionnalité peut être activée sur des routeurs individuels sans être activée ou disponible sur d’autres routeurs qui peuvent ne pas prendre en charge cette fonctionnalité. Les routeurs voisins n’ont pas besoin de connaître le calcul de surabonnement, ils s’appuient sur l’IGP.

Les sections suivantes décrivent les types de surabonnement de bande passante disponibles dans Junos OS :

Surabonnement de taille LSP

Pour un surabonnement de taille LSP, il vous suffit de configurer une bande passante inférieure au débit maximal attendu pour le LSP. Vous devrez peut-être également ajuster la configuration des mécanismes de contrôle automatiques. Les mécanismes de contrôle automatiques gèrent le trafic affecté à un LSP, en veillant à ce qu’il ne dépasse pas les valeurs de bande passante configurées. Le surabonnement de taille du LSP nécessite que le LSP puisse dépasser son allocation de bande passante configurée.

Le maintien de l’ordre est toujours possible. Toutefois, le mécanisme de contrôle doit être configuré manuellement pour tenir compte de la bande passante maximale prévue pour le LSP, plutôt que de la valeur configurée.

Multiplicateurs de surabonnement de type de classe et de surabonnement local

Les multiplicateurs de surabonnement locaux (LOM) permettent des valeurs de surabonnement différentes pour différents types de classes. Les LOM sont utiles pour les réseaux où le taux de surabonnement doit être configuré différemment sur différentes liaisons et où des valeurs de surabonnement sont requises pour différentes classes. Vous pouvez utiliser cette fonctionnalité pour surabonner les types de classe gérant le trafic « best effort », mais n’utilisez pas de surabonnement pour les types de classe gérant le trafic vocal. Une LOM est calculée localement sur le routeur. Aucune information relative à un LOM n’est signalée aux autres routeurs du réseau.

Une LOM est configurable sur chaque liaison et pour chaque type de classe. La LOM de type par classe vous permet d’augmenter ou de diminuer le taux de sursouscription. La LOM de type par classe est prise en compte dans l’ensemble de la bande passante locale pour le contrôle d’admission et l’annonce IGP des bandes passantes non réservées.

Le calcul de la LOM est lié au modèle de bande passante (MAM, MAM étendue et poupées russes) utilisé, car l’effet du surabonnement entre les types de classes doit être pris en compte avec précision.

REMARQUE :

Tous les calculs LOM sont effectués par Junos OS et ne nécessitent aucune intervention de l’utilisateur.

Les formules relatives à la sursouscription de types de classes sont décrites dans les sections suivantes :

Configuration du pourcentage d’abonnement à la bande passante pour les prestataires de services linguistiques

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

Si vous souhaitez surabonner ou sous-abonner tous les types de classes sur une interface en utilisant le même pourcentage de bande passante, configurez le pourcentage à l’aide de l’instruction subscription :

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

Pour sous-abonner ou surabonner la bande passante pour chaque type de classe, configurez un pourcentage pour chaque option de type de classe (ct0, ct1, ct2et ct3) pour l’instruction subscription . Lorsque vous surabonnez un type de classe, une LOM est appliquée pour calculer la bande passante réellement réservée. Pour plus d’informations, reportez-vous à la section Surabonnement de type de classe et Multiplicateurs de surabonnement local .

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

percentage est le pourcentage de bande passante de type classe que RSVP permet d’utiliser pour les réservations. Il peut s’agir d’une valeur comprise entre 0 et 65 000 %. Si vous spécifiez une valeur supérieure à 100, vous surabonnez le type d’interface ou de classe.

La valeur que vous configurez lorsque vous surabonnez un type de classe est un pourcentage de la bande passante du type de classe qui peut réellement être utilisée. La valeur d’abonnement par défaut est de 100 %.

Vous pouvez utiliser l’instruction pour désactiver les subscription nouvelles sessions RSVP pour un ou plusieurs types de cours. Si vous configurez un pourcentage de 0, aucune nouvelle session (y compris celles qui n’ont aucune exigence de bande passante) n’est autorisée pour le type de classe.

Les sessions RSVP existantes ne sont pas affectées par la modification du facteur d’abonnement. Pour effacer une session existante, exécutez la clear rsvp session commande. Pour plus d’informations sur la clear rsvp session commande, consultez l’Explorateur CLI.

Contraintes liées à la configuration de l’abonnement à la bande passante

Lors de la configuration de l’abonnement à la bande passante, tenez compte des problèmes suivants :

  • Si vous configurez des contraintes de bande passante au niveau de la hiérarchie, elles remplacent toute configuration de bande passante que vous spécifiez au niveau de la [edit class-of-service interface interface-name][edit protocols rsvp interface interface-name bandwidth] hiérarchie pour Diffserv-TE. Notez également que les contraintes de bande passante CoS ou RSVP peuvent remplacer les contraintes de bande passante matérielle de l’interface.

  • Si vous configurez une valeur d’abonnement de bande passante pour une interface spécifique qui diffère de la valeur configurée pour toutes les interfaces (en incluant des valeurs différentes pour l’instruction au niveau de la hiérarchie et [edit protocols rsvp interface all] ), la [edit protocols rsvp interface interface-name] valeur spécifique à l’interface subscription est utilisée pour cette interface.

  • Vous pouvez configurer l’abonnement pour chaque type de cours uniquement si vous configurez également un modèle de bande passante. Si aucun modèle de bande passante n’est configuré, l’opération de validation échoue avec le message d’erreur suivant :

  • Vous ne pouvez pas inclure l’instruction à la fois dans la configuration d’un type de classe spécifique et dans la configuration de l’interface subscription entière. L’opération de validation échoue avec le message d’erreur suivant :

Tableau de l'historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Version
Description
14.1R9
À compter de Junos OS version 14.1R9, 15.1R7, 16.1R5, 16.1X2, 16.2R3 et 17.2R2, tous les échantillons de bande passante à valeur nulle sont considérés comme des échantillons de sous-flux, à l’exception des échantillons à valeur nulle qui arrivent après la première apparition d’un LSP et des échantillons à valeur nulle qui arrivent en premier après un basculement du moteur de routage.