Sur cette page
Configuration d’une description textuelle pour les prestataires de services linguistiques
Configuration de la priorité et de la préemption pour les LSP
Configuration des groupes d’administration pour les prestataires de services linguistiques
Configuration de groupes d’administration étendus pour les prestataires de services linguistiques
Désactivation de l’enregistrement de route de chemin par les LSP
Réussir une transition sans impact pour les prestataires de services linguistiques
Configuration de l’allocation automatique de bande passante pour les LSP
Configuration des ajustements optimisés de la bande passante automatique pour les LSP MPLS
Example: Configuring an Entropy Label for a BGP Labeled Unicast LSP
Multiplicateurs de surabonnement de type de classe et de surabonnement local
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
- Configuration des métriques LSP statiques
- Configuration des métriques conditionnelles RSVP LSP
- Préserver la métrique IGP dans les routes RSVP LSP
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 :
metric number;
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
-
[edit protocols mpls label-switched-path lsp-name]
-
[edit protocols mpls static-label-switched-path lsp-name]
-
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]
-
[edit logical-systems logical-system-name protocols mpls static-label-switched-path lsp-name]
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-metric
conditional-metric
RSVP.
Exécutez la show route protocol rsvp extensive
commande pour afficher le coût IGP réel mis à jour.
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 lsp
show 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 :
-
[edit protocols mpls label-switched-path lsp-name]
-
[edit protocols mpls container-label-switched-path lsp-name]
-
[edit protocols mpls static-label-switched-path lsp-name]
-
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]
-
[edit logical-systems logical-system-name protocols mpls static-label-switched-path lsp-name]
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 :
-
Saisissez n’importe quel texte décrivant le LSP.
[edit protocols mpls lsp lsp-name] user@host# set description text
Par exemple :
[edit protocols mpls lsp LSP1] user@host# set description “Connecting remote device”
-
Vérifiez et validez la configuration.
Par exemple :
[edit protocols mpls lsp] user@host# set protocols mpls label-switched-path LSP1 to 10.1.1.1 user@host# set protocols mpls label-switched-path LSP1 description "Connecting remote device" user@host# set protocols mpls interface ge-1/0/8.0
[edit] user@host# commit commit complete
-
Affichez la description d’un LSP à l’aide de la
show mpls lsp detail
commande oushow mpls container-lsp detail
, en fonction du type de LSP configuré.user@host> show mpls lsp detail Ingress LSP: 1 sessions 10.1.1.1 From: 0.0.0.0, State: Up, ActiveRoute: 1, LSPname: LSP1 Description: Connecting remote device ActivePath: (none) LSPtype: Static Configured, Penultimate hop popping LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 Primary State: Up Priorities: 7 0 SmartOptimizeTimer: 180 No computed ERO. Total 1 displayed, Up 1, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
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
:
soft-preemption;
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
[edit protocols mpls label-switched-path lsp-name]
[edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]
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
:
cleanup-timer seconds;
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
[edit protocols rsvp preemption soft-preemption]
[edit logical-systems logical-system-name protocols rsvp preemption soft-preemption]
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.
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 :
priority setup-priority reservation-priority;
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.
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 :
Définissez plusieurs niveaux de qualité de service en incluant l’instruction
admin-groups
suivante :admin-groups { group-name group-value; }
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 :
[edit protocols mpls] admin-groups { gold 1; silver 2; copper 3; best-effort 4; }
Définissez les groupes d’administration auxquels appartient une interface. Vous pouvez affecter plusieurs groupes à une interface. Incluez l’énoncé
interface
suivant :interface interface-name { admin-group [ group-names ]; }
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.
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 :label-switched-path lsp-name { to address; ... admin-group { exclude [ group-names ]; include-all [ group-names ]; include-any [ group-names ]; } primary path-name { admin-group { exclude [ group-names ]; include-all [ group-names ]; include-any [ group-names ]; } } secondary path-name { admin-group { exclude [ group-names ]; include-all [ group-names ]; include-any [ group-names ]; } } }
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-all
instructions , ou ,include-any
leexclude
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 :
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 :
preference preference;
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 :
no-record;
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-delay
optimize-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
- Spécification de la durée pendant laquelle il faut retarder le démantèlement des anciens chemins
- Passer au MBB sans heurts et sans retards artificiels
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
:
optimize-switchover-delay seconds;
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 :
optimize-hold-dead-delay seconds;
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.
optimize-adaptive-teardown { p2p: }
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 :
optimize-timer seconds;
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 :
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.)
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.
L’encombrement relatif du nouveau trajet est déterminé comme suit :
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.
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.
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.
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.
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 :
Si la métrique IGP du nouveau chemin est inférieure, elle est acceptée.
Si le nouveau chemin a une métrique IGP égale et un nombre de sauts inférieur, il est accepté.
Si vous choisissez
least-fill
un algorithme d’équilibrage de charge, les LSP sont équilibrés en charge comme suit :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 %.
Pour
random
les algorithmes oumost-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 remplissageComme 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.
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
:
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
:
smart-optimize-timer seconds;
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 :
hop-limit number;
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 :
bandwidth bps;
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.
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 :
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 :
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’instructionload-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.
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
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:
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.
interfaces { et-0/0/0:1 { unit 0 { family { mpls; } } } } protocols { mpls { label-switched-path lsp1 { to 10.2.5.1; in-place-lsp-bandwidth-update; } } }
To Configure Per-priority Subscription:
Configurez le protocole RSVP sur l’interface.
[edit] user@host# set protocols rsvp interfaceinterface-name user@host# set protocols rsvp interface et-0/0/0:1.0
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 %.
[edit] user@host# set protocols rsvp interface interface-name subscription percentage
user@host# set protocols rsvp et-0/0/0:1.0 subscription 11
Configurez la priorité d’abonnement sur l’interface.
[edit] user@host# set protocols rsvp interface interface-name subscription percentage priority
user@host# set protocols rsvp et-0/0/0:1.0 subscription 11 priority 7
Configurez le pourcentage d’abonnement pour la priorité.
[edit] user@host# set protocols rsvp interface interface-name subscription percentage priority percentage
user@host# set protocols rsvp et-0/0/0:1.0 subscription 11 priority 7 percent 10
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.
protocols { rsvp { interface et-0/0/0:1.0 { subscription 11{ priority 7 { percent 10; } } }
Voir également
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 :
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 :
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 :
advertisement-hold-time seconds;
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.
Pour configurer un LSP bidirectionnel corouté :
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 :
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:
-
Configure the device interfaces.
-
Configure OSPF or any other IGP protocol.
-
Configure BGP.
-
Configure RSVP.
-
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.
[edit forwarding-options]
user@PE#no-load-balance-label-capability
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.
[edit policy-options policy-statement policy-name then]
user@PE#no-entropy-label-capability
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.
Configuration
- CLI Quick Configuration
- Configuring Router PE1
- Configuring Router P1
- Configuring Router ABR
- (Optional) Port-Mirroring 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
set interfaces ge-0/0/0 unit 0 family inet address 172.16.12.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.1/32 primary set interfaces lo0 unit 0 family inet address 192.168.255.1/32 set routing-options router-id 172.16.255.1 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive
Router PE1
set interfaces ge-0/0/0 unit 0 family inet address 172.16.12.2/30 set interfaces ge-0/0/2 unit 0 family inet address 10.1.23.1/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.1.255.2/32 primary set interfaces lo0 unit 1 family inet address 10.1.255.22/32 set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf then accept set policy-options policy-statement pplb then load-balance per-packet set routing-instances VPN-l3vpn instance-type vrf set routing-instances VPN-l3vpn protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set routing-instances VPN-l3vpn protocols ospf area 0.0.0.0 interface lo0.1 passive set routing-instances VPN-l3vpn protocols ospf export bgp-to-ospf set routing-instances VPN-l3vpn interface ge-0/0/0.0 set routing-instances VPN-l3vpn interface lo0.1 set routing-instances VPN-l3vpn route-distinguisher 10.1.255.2:1 set routing-instances VPN-l3vpn vrf-target target:65000:1 set routing-options router-id 10.1.255.2 set routing-options autonomous-system 65000 set routing-options forwarding-table export pplb set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.1.255.2 set protocols bgp group ibgp family inet labeled-unicast entropy-label set protocols bgp group ibgp neighbor 10.1.255.4 family inet labeled-unicast rib inet.3 set protocols bgp group ibgp neighbor 10.1.255.6 family inet-vpn unicast set protocols mpls icmp-tunneling set protocols mpls label-switched-path pe1-abr to 10.1.255.4 set protocols mpls label-switched-path pe1-abr entropy-label set protocols mpls interface ge-0/0/2.0 set protocols mpls interface lo0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols rsvp interface ge-0/0/2.0 set protocols rsvp interface lo0.0
Router P1
set interfaces ge-0/0/0 unit 0 family inet address 10.1.23.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.1.34.1/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.1.255.3/32 primary set routing-options router-id 10.1.255.3 set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/0.0 set protocols mpls interface lo0.0 set protocols mpls interface ge-0/0/2.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/2.0
Router ABR
set interfaces ge-0/0/0 unit 0 family inet address 10.1.34.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.1.45.1/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 10.1.45.5/30 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.1.255.4/32 primary set forwarding-options hash-key family mpls label-1 set forwarding-options hash-key family mpls label-2 set forwarding-options hash-key family mpls label-3 set forwarding-options enhanced-hash-key family mpls no-payload set policy-options policy-statement pplb then load-balance per-packet set policy-options policy-statement send-inet3-pe1 from route-filter 10.1.255.2/32 exact set policy-options policy-statement send-inet3-pe1 then accept set policy-options policy-statement send-inet3-pe2 from route-filter 10.1.255.6/32 exact set policy-options policy-statement send-inet3-pe2 then accept set routing-options router-id 10.1.255.4 set routing-options autonomous-system 65000 set routing-options forwarding-table export pplb set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.1.255.4 set protocols bgp group ibgp family inet labeled-unicast rib inet.3 set protocols bgp group ibgp neighbor 10.1.255.2 export send-inet3-pe2 set protocols bgp group ibgp neighbor 10.1.255.6 export send-inet3-pe1 set protocols mpls icmp-tunneling set protocols mpls label-switched-path abr-pe1 to 10.1.255.2 set protocols mpls label-switched-path abr-pe1 entropy-label set protocols mpls label-switched-path abr-pe2 to 10.1.255.6 set protocols mpls label-switched-path abr-pe2 entropy-label set protocols mpls label-switched-path abr-pe2 primary to-r6-1 set protocols mpls label-switched-path abr-pe2-2 to 10.1.255.6 set protocols mpls label-switched-path abr-pe2-2 entropy-label set protocols mpls label-switched-path abr-pe2-2 primary to-r6-2 set protocols mpls path to-r6-1 10.1.45.2 strict set protocols mpls path to-r6-1 10.1.56.2 strict set protocols mpls path to-r6-2 10.1.45.6 strict set protocols mpls path to-r6-2 10.1.56.6 strict set protocols mpls interface lo0.0 set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.1 interface ge-0/0/2.0 set protocols ospf area 0.0.0.1 interface ge-0/0/3.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/2.0 set protocols rsvp interface ge-0/0/3.0
Router P2
set interfaces ge-0/0/0 unit 0 family inet address 10.1.45.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.1.45.6/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.1.56.1/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 10.1.56.5/30 set interfaces ge-0/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.1.255.5/32 primary set forwarding-options hash-key family mpls label-1 set forwarding-options hash-key family mpls label-2 set forwarding-options hash-key family mpls label-3 set forwarding-options enhanced-hash-key family mpls no-payload set policy-options policy-statement pplb then load-balance per-packet set routing-options router-id 10.1.255.5 set routing-options forwarding-table export pplb set protocols mpls icmp-tunneling set protocols mpls interface ge-0/0/2.0 set protocols mpls interface lo0.0 set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/3.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.1 interface lo0.0 passive set protocols ospf area 0.0.0.1 interface ge-0/0/2.0 set protocols ospf area 0.0.0.1 interface ge-0/0/0.0 set protocols ospf area 0.0.0.1 interface ge-0/0/1.0 set protocols ospf area 0.0.0.1 interface ge-0/0/3.0 set protocols rsvp interface ge-0/0/2.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/3.0
Router PE2
set interfaces ge-0/0/0 unit 0 family inet address 10.1.56.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.1.56.6/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 172.16.67.2/30 set interfaces lo0 unit 0 family inet address 10.1.255.6/32 primary set interfaces lo0 unit 1 family inet address 10.1.255.66/32 set forwarding-options hash-key family mpls label-1 set forwarding-options hash-key family mpls label-2 set forwarding-options hash-key family mpls label-3 set forwarding-options enhanced-hash-key family mpls no-payload set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf then accept set policy-options policy-statement pplb then load-balance per-packet set routing-instances VPN-l3vpn instance-type vrf set routing-instances VPN-l3vpn protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set routing-instances VPN-l3vpn protocols ospf area 0.0.0.0 interface lo0.1 passive set routing-instances VPN-l3vpn protocols ospf export bgp-to-ospf set routing-instances VPN-l3vpn interface ge-0/0/2.0 set routing-instances VPN-l3vpn interface lo0.1 set routing-instances VPN-l3vpn route-distinguisher 10.1.255.6:1 set routing-instances VPN-l3vpn vrf-target target:65000:1 set routing-options router-id 10.1.255.6 set routing-options autonomous-system 65000 set routing-options forwarding-table export pplb set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.1.255.6 set protocols bgp group ibgp family inet labeled-unicast entropy-label set protocols bgp group ibgp neighbor 10.1.255.4 family inet labeled-unicast rib inet.3 set protocols bgp group ibgp neighbor 10.1.255.2 family inet-vpn unicast set protocols mpls icmp-tunneling set protocols mpls label-switched-path pe2-abr to 10.1.255.4 set protocols mpls label-switched-path pe2-abr entropy-label set protocols mpls interface ge-0/0/0.0 set protocols mpls interface lo0.0 set protocols mpls interface ge-0/0/1.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.1 interface ge-0/0/0.0 set protocols ospf area 0.0.0.1 interface lo0.0 passive set protocols ospf area 0.0.0.1 interface ge-0/0/1.0 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface lo0.0 set protocols rsvp interface ge-0/0/1.0
Router CE2
set interfaces ge-0/0/0 unit 0 family inet address 172.16.67.1/30 set interfaces lo0 unit 0 family inet address 172.16.255.7/32 primary set interfaces lo0 unit 0 family inet address 192.168.255.7/32 set routing-options router-id 172.16.255.7 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive
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:
Repeat this procedure for Router PE2 after modifying the appropriate interface names, addresses, and other parameters.
-
Configure the physical interfaces. Ensure to configure
family mpls
on the core facing interface.[edit] user@PE1# set interfaces ge-0/0/0 unit 0 family inet address 172.16.12.2/30 user@PE1# set interfaces ge-0/0/2 unit 0 family inet address 10.1.23.1/30 user@PE1# set interfaces ge-0/0/2 unit 0 family mpls
-
Configure the loopback interfaces. The secondary loopback is optional and is applied under the routing instance in a later step.
[edit] user@PE1# set interfaces lo0 unit 0 family inet address 10.1.255.2/32 primary user@PE1# set interfaces lo0 unit 1 family inet address 10.1.255.22/32
-
Configure the router ID and the autonomous system number.
[edit] user@PE1# set routing-options router-id 10.1.255.2 user@PE1# set routing-options autonomous-system 65000
-
Configure the OSPF protocol.
[edit] user@PE1# set protocols ospf traffic-engineering user@PE1# set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 user@PE1# set protocols ospf area 0.0.0.0 interface lo0.0 passive
-
Configure the RSVP protocol.
[edit] user@PE1# set protocols rsvp interface ge-0/0/2.0 user@PE1# set protocols rsvp interface lo0.0
-
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.[edit protocols] user@PE1# set protocols mpls icmp-tunneling user@PE1# set protocols mpls label-switched-path pe1-abr to 10.1.255.4 user@PE1# set protocols mpls label-switched-path pe1-abr entropy-label user@PE1# set protocols mpls interface ge-0/0/2.0 user@PE1# set protocols mpls interface lo0.0
-
Configure IBGP using
family inet labeled-unicast
for the ABR peering andfamily inet-vpn
for the PE2 peering. Enable entropy label capability for BGP labeled unicast.[edit] user@PE1# set protocols bgp group ibgp type internal user@PE1# set protocols bgp group ibgp local-address 10.1.255.2 user@PE1# set protocols bgp group ibgp family inet labeled-unicast entropy-label user@PE1# set protocols bgp group ibgp neighbor 10.1.255.4 family inet labeled-unicast rib inet.3 user@PE1# set protocols bgp group ibgp neighbor 10.1.255.6 family inet-vpn unicast
-
Define a policy to export BGP VPN routes into OSPF. The policy is applied under OSPF in the routing instance.
[edit] user@PE1# set policy-options policy-statement bgp-to-ospf from protocol bgp user@PE1# set policy-options policy-statement bgp-to-ospf then accept
-
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.[edit] user@PE1# set policy-options policy-statement pplb then load-balance per-packet user@PE1# set routing-options forwarding-table export pplb
-
Configure the Layer 3 VPN routing instance.
[edit] user@PE1# set routing-instances VPN-l3vpn instance-type vrf
-
Assign the interfaces to the routing instance.
[edit] user@PE1# set routing-instances VPN-l3vpn interface ge-0/0/0.0 user@PE1# set routing-instances VPN-l3vpn interface lo0.1
-
Configure the route distinguisher for the routing instance.
[edit] user@PE1# set routing-instances VPN-l3vpn route-distinguisher 10.1.255.2:1
-
Configure a VPN routing and forwarding (VRF) target for the routing instance.
[edit] user@PE1# set routing-instances VPN-l3vpn vrf-target target:65000:1
-
Configure the protocol OSPF under the routing instance and apply the previously configured
bgp-to-ospf
policy.[edit] user@PE1# set routing-instances VPN-l3vpn protocols ospf area 0.0.0.0 interface ge-0/0/0.0 user@PE1# set routing-instances VPN-l3vpn protocols ospf area 0.0.0.0 interface lo0.1 passive user@PE1# set routing-instances VPN-l3vpn protocols ospf export bgp-to-ospf
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:
Repeat this procedure for Router P2 after modifying the appropriate interface names, addresses, and other parameters.
-
Configure the physical interfaces.
[edit] user@P1# set interfaces ge-0/0/0 unit 0 family inet address 10.1.23.2/30 user@P1# set interfaces ge-0/0/0 unit 0 family mpls user@P1# set interfaces ge-0/0/2 unit 0 family inet address 10.1.34.1/30 user@P1# set interfaces ge-0/0/2 unit 0 family mpls
-
Configure the loopback interface.
[edit] user@P1# set interfaces lo0 unit 0 family inet address 10.1.255.3/32 primary
-
Configure the router ID.
[edit] user@P1# set routing-options router-id 10.1.255.3
-
Configure the OSPF protocol.
[edit] user@P1# set protocols ospf traffic-engineering user@P1# set protocols ospf area 0.0.0.0 interface lo0.0 passive user@P1# set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 user@P1# set protocols ospf area 0.0.0.0 interface ge-0/0/2.0
-
Configure the RSVP protocol.
[edit] user@P1# set protocols rsvp interface ge-0/0/0.0 user@P1# set protocols rsvp interface lo0.0 user@P1# set protocols rsvp interface ge-0/0/2.0
-
Configure the MPLS protocol.
[edit] user@P1# set protocols mpls icmp-tunneling user@P1# set protocols mpls interface ge-0/0/0.0 user@P1# set protocols mpls interface lo0.0 user@P1# set protocols mpls interface ge-0/0/2.0
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:
-
Configure the physical interfaces.
[edit] user@ABR# set interfaces ge-0/0/0 unit 0 family inet address 10.1.34.2/30 user@ABR# set interfaces ge-0/0/0 unit 0 family mpls user@ABR# set interfaces ge-0/0/2 unit 0 family inet address 10.1.45.1/30 user@ABR# set interfaces ge-0/0/2 unit 0 family mpls user@ABR# set interfaces ge-0/0/3 unit 0 family inet address 10.1.45.5/30 user@ABR# set interfaces ge-0/0/3 unit 0 family mpls
-
Configure the loopback interface.
[edit] user@ABR# set interfaces lo0 unit 0 family inet address 10.1.255.4/32 primary
-
Configure MPLS labels that the router uses for hashing the packets to its destination for load balancing.
[edit] user@ABR# set forwarding-options hash-key family mpls label-1 user@ABR# set forwarding-options hash-key family mpls label-2 user@ABR# set forwarding-options hash-key family mpls label-3 user@ABR# set forwarding-options enhanced-hash-key family mpls no-payload
-
Configure the router ID and the autonomous system number.
[edit] user@ABR# set routing-options router-id 10.1.255.4 user@ABR# set routing-options autonomous-system 65000
-
Configure the OSPF protocol.
[edit] user@ABR# set protocols ospf traffic-engineering user@ABR# set protocols ospf area 0.0.0.0 interface lo0.0 passive user@ABR# set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 user@ABR# set protocols ospf area 0.0.0.1 interface ge-0/0/2.0 user@ABR# set protocols ospf area 0.0.0.1 interface ge-0/0/3.0
-
Configure the RSVP protocol.
[edit] user@ABR# set protocols rsvp interface lo0.0 user@ABR# set protocols rsvp interface ge-0/0/0.0 user@ABR# set protocols rsvp interface ge-0/0/2.0 user@ABR# set protocols rsvp interface ge-0/0/3.0
-
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.
[edit] user@ABR# set protocols mpls icmp-tunneling user@ABR# set protocols mpls label-switched-path abr-pe1 to 10.1.255.2 user@ABR# set protocols mpls label-switched-path abr-pe1 entropy-label user@ABR# set protocols mpls label-switched-path abr-pe2 to 10.1.255.6 user@ABR# set protocols mpls label-switched-path abr-pe2 entropy-label user@ABR# set protocols mpls label-switched-path abr-pe2 primary to-r6-1 user@ABR# set protocols mpls label-switched-path abr-pe2-2 to 10.1.255.6 user@ABR# set protocols mpls label-switched-path abr-pe2-2 entropy-label user@ABR# set protocols mpls label-switched-path abr-pe2-2 primary to-r6-2 user@ABR# set protocols mpls path to-r6-1 10.1.45.2 strict user@ABR# set protocols mpls path to-r6-1 10.1.56.2 strict user@ABR# set protocols mpls path to-r6-2 10.1.45.6 strict user@ABR# set protocols mpls path to-r6-2 10.1.56.6 strict user@ABR# set protocols mpls interface lo0.0 user@ABR# set protocols mpls interface ge-0/0/0.0 user@ABR# set protocols mpls interface ge-0/0/2.0 user@ABR# set protocols mpls interface ge-0/0/3.0
-
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.[edit] user@ABR# set protocols bgp group ibgp type internal user@ABR# set protocols bgp group ibgp local-address 10.1.255.4 user@ABR# set protocols bgp group ibgp family inet labeled-unicast rib inet.3 user@ABR# set protocols bgp group ibgp neighbor 10.1.255.2 export send-inet3-pe2 user@ABR# set protocols bgp group ibgp neighbor 10.1.255.6 export send-inet3-pe1
-
Define a policy to match on the loopback addresses for PE1 and PE2.
[edit] user@ABR# set policy-options policy-statement send-inet3-pe1 from route-filter 10.1.255.2/32 exact user@ABR# set policy-options policy-statement send-inet3-pe1 then accept user@ABR# set policy-options policy-statement send-inet3-pe2 from route-filter 10.1.255.6/32 exact user@ABR# set policy-options policy-statement send-inet3-pe2 then accept
-
Define a policy for load balancing and apply it under the
routing-options forwarding-table
.[edit] user@ABR# set policy-options policy-statement pplb then load-balance per-packet user@ABR# set routing-options forwarding-table export pplb
(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:
-
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.
[edit] user@P1# set interfaces ge-0/0/4 unit 0 family bridge interface-mode access user@P1# set interfaces ge-0/0/4 unit 0 family bridge vlan-id 100 user@P1# set interfaces irb unit 0 family inet address 10.1.31.1/30
-
Configure the bridge domain.
[edit] user@P1# set bridge-domains v100 vlan-id 100 user@P1# set bridge-domains v100 routing-interface irb.0
-
Configure a filter to capture the traffic. For this example we are capturing all traffic.
[edit] user@P1# set firewall family any filter test term 1 then count test user@P1# set firewall family any filter test term 1 then port-mirror user@P1# set firewall family any filter test term 1 then accept
-
Apply the filter to the PE1 facing interface.
[edit] user@P1# set interfaces ge-0/0/0 unit 0 filter input test
-
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.
[edit] user@P1# set forwarding-options port-mirroring input rate 1 user@P1# set forwarding-options port-mirroring family any output interface ge-0/0/4.0
Verification
Confirm that the configuration is working properly.
- Verifying That the Entropy Label Capability Is Being Advertised
- Verifying That Router PE1 Receives the Entropy Label Advertisement
- Verifying ECMP at the ABR to PE2
- Show Routes to CE2 on PE1
- Ping CE2 from CE1
- Verify Load Balancing
- Verify the Entropy Label
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.
user@ABR> show route advertising-protocol bgp 10.1.255.2 detail inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) * 10.1.255.6/32 (1 entry, 1 announced) BGP group ibgp type Internal Route Label: 299952 Nexthop: Self Flags: Nexthop Change MED: 2 Localpref: 4294967294 AS path: [65000] I Entropy label capable
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.
user@PE1> show route protocol bgp 10.1.255.6 extensive inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 10.1.255.6/32 (1 entry, 1 announced) *BGP Preference: 170/1 Next hop type: Indirect, Next hop index: 0 Address: 0x7b3ffd4 Next-hop reference count: 2, key opaque handle: 0x0, non-key opaque handle: 0x0 Source: 10.1.255.4 Next hop type: Router, Next hop index: 0 Next hop: 10.1.23.2 via ge-0/0/2.0, selected Label-switched-path pe1-abr Label operation: Push 299952, Push 299808(top) Label TTL action: prop-ttl, prop-ttl(top) Load balance label: Label 299952: Entropy label; Label 299808: None; Label element ptr: 0x93d6bf8 Label parent element ptr: 0x93d6c20 Label element references: 3 Label element child references: 2 Label element lsp id: 0 Session Id: 0 Protocol next hop: 10.1.255.4 Label operation: Push 299952 Label TTL action: prop-ttl Load balance label: Label 299952: Entropy label; Indirect next hop: 0x758c05c - INH Session ID: 0 State: <Active Int Ext> Local AS: 65000 Peer AS: 65000 Age: 1:33:11 Metric: 2 Metric2: 2 Validation State: unverified Task: BGP_65000.10.1.255.4 Announcement bits (2): 3-Resolve tree 1 4-Resolve_IGP_FRR task AS path: I Accepted Route Label: 299952 Localpref: 4294967294 Router ID: 10.1.255.4 Session-IDs associated: Session-id: 324 Version: 3 Thread: junos-main Indirect next hops: 1 Protocol next hop: 10.1.255.4 Metric: 2 ResolvState: Resolved Label operation: Push 299952 Label TTL action: prop-ttl Load balance label: Label 299952: Entropy label; Indirect next hop: 0x758c05c - INH Session ID: 0 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 10.1.23.2 via ge-0/0/2.0 Session Id: 0 10.1.255.4/32 Originating RIB: inet.3 Metric: 2 Node path count: 1 Forwarding nexthops: 1 Next hop type: Router Next hop: 10.1.23.2 via ge-0/0/2.0 Session Id: 0
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.
user@ABR> show route table mpls.0 mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0 *[MPLS/0] 2w1d 23:02:11, metric 1 Receive 1 *[MPLS/0] 2w1d 23:02:11, metric 1 Receive 2 *[MPLS/0] 2w1d 23:02:11, metric 1 Receive 13 *[MPLS/0] 2w1d 23:02:11, metric 1 Receive 299936 *[VPN/170] 2d 21:47:02 > to 10.1.34.1 via ge-0/0/0.0, label-switched-path abr-pe1 299952 *[VPN/170] 2d 21:47:02 > to 10.1.45.2 via ge-0/0/2.0, label-switched-path abr-pe2 to 10.1.45.6 via ge-0/0/3.0, label-switched-path abr-pe2-2 ruser@ABR> show route forwarding-table label 299952 Routing table: default.mpls MPLS: Destination Type RtRef Next hop Type Index NhRef Netif 299952 user 0 ulst 1048575 2 10.1.45.2 Swap 299824 516 2 ge-0/0/2.0 10.1.45.6 Swap 299840 572 2 ge-0/0/3.0 ...
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.
user@PE1> show route table VPN-l3vpn.inet.0 172.16.255.7 extensive VPN-l3vpn.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) 172.16.255.7/32 (1 entry, 1 announced) TSI: OSPF area : 0.0.0.0, LSA ID : 172.16.255.7, LSA type : Summary KRT in-kernel 172.16.255.7/32 -> {indirect(1048574)} *BGP Preference: 170/-101 Route Distinguisher: 10.1.255.6:1 Next hop type: Indirect, Next hop index: 0 Address: 0x7b40434 Next-hop reference count: 9, key opaque handle: 0x0, non-key opaque handle: 0x0 Source: 10.1.255.6 Next hop type: Router, Next hop index: 515 Next hop: 10.1.23.2 via ge-0/0/2.0, selected Label-switched-path pe1-abr Label operation: Push 299824, Push 299952, Push 299808(top) Label TTL action: prop-ttl, prop-ttl, prop-ttl(top) Load balance label: Label 299824: None; Label 299952: Entropy label; Label 299808: None; Label element ptr: 0x93d6c98 Label parent element ptr: 0x93d6bf8 Label element references: 1 Label element child references: 0 Label element lsp id: 0 Session Id: 140 Protocol next hop: 10.1.255.6 Label operation: Push 299824 Label TTL action: prop-ttl Load balance label: Label 299824: None; ... user@PE1> show route table VPN-l3vpn.inet.0 192.168.255.7 extensive VPN-l3vpn.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) 192.168.255.7/32 (1 entry, 1 announced) TSI: OSPF area : 0.0.0.0, LSA ID : 192.168.255.7, LSA type : Summary KRT in-kernel 192.168.255.7/32 -> {indirect(1048574)} *BGP Preference: 170/-101 Route Distinguisher: 10.1.255.6:1 Next hop type: Indirect, Next hop index: 0 Address: 0x7b40434 Next-hop reference count: 9, key opaque handle: 0x0, non-key opaque handle: 0x0 Source: 10.1.255.6 Next hop type: Router, Next hop index: 515 Next hop: 10.1.23.2 via ge-0/0/2.0, selected Label-switched-path pe1-abr Label operation: Push 299824, Push 299952, Push 299808(top) Label TTL action: prop-ttl, prop-ttl, prop-ttl(top) Load balance label: Label 299824: None; Label 299952: Entropy label; Label 299808: None; Label element ptr: 0x93d6c98 Label parent element ptr: 0x93d6bf8 Label element references: 1 Label element child references: 0 Label element lsp id: 0 Session Id: 140 Protocol next hop: 10.1.255.6 Label operation: Push 299824 Label TTL action: prop-ttl Load balance label: Label 299824: None; ...
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.
user@CE1> ping 172.16.255.7 source 172.16.12.1 rapid count 100 PING 172.16.255.7 (172.16.255.7): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --- 172.16.255.7 ping statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max/stddev = 5.369/6.070/8.828/0.612 ms user@CE1> ping 192.168.255.7 source 192.168.255.1 rapid count 200 PING 192.168.255.7 (192.168.255.7): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --- 192.168.255.7 ping statistics --- 200 packets transmitted, 200 packets received, 0% packet loss round-trip min/avg/max/stddev = 5.086/5.994/10.665/0.649 ms
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.
user@ABR> show mpls lsp ingress statistics Ingress LSP: 3 sessions To From State Packets Bytes LSPname 10.1.255.2 10.1.255.4 Up 300 30000 abr-pe1 10.1.255.6 10.1.255.4 Up 200 20000 abr-pe2 10.1.255.6 10.1.255.4 Up 100 10000 abr-pe2-2 Total 3 displayed, Up 3, Down 0
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.
user@Host1# tcpdump -i eth1 -n ... 13:42:31.993274 MPLS (label 299808, exp 0, ttl 63) (label 299952, exp 0, ttl 63) (label 7, exp 0, ttl 63) (label 1012776, exp 0, ttl 0) (label 299824, exp 0, [S], ttl 63) IP 172.16.12.1 > 172.16.255.7: ICMP echo request, id 32813, seq 9, length 64 ... 13:43:19.570260 MPLS (label 299808, exp 0, ttl 63) (label 299952, exp 0, ttl 63) (label 7, exp 0, ttl 63) (label 691092, exp 0, ttl 0) (label 299824, exp 0, [S], ttl 63) IP 192.168.255.1 > 192.168.255.7: ICMP echo request, id 46381, seq 9, length 64
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.
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).
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’étiquette
vrf-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.
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 :
-
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’attributloose
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.
-
Pour configurer le LSP et le faire pointer vers le chemin nommé, utilisez l’instruction
primary
ousecondary
, comme décrit dans Configuration des LSP principaux et secondaires. -
Désactivez le calcul du LSP à chemin contraint en incluant l’instruction dans le LSP ou dans le cadre d’une
no-cspf
primary
instruction orsecondary
. Pour plus d’informations, consultez Désactivation du calcul LSP à chemin contraint. -
Configurez toutes les autres propriétés LSP.
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.
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
[edit] interfaces { so-0/0/0 { unit 0 { family mpls; } } } protocols { rsvp { interface so-0/0/0; } mpls { path to-hastings { 14.1.1.1 strict; 13.1.1.1 strict; 12.1.1.1 strict; 11.1.1.1 strict; } path alt-hastings { 14.1.1.1 strict; 11.1.1.1 loose; # Any IGP route is acceptable } label-switched-path hastings { to 11.1.1.1; hop-limit 32; bandwidth 10m; # Reserve 10 Mbps no-cspf; # do not perform constrained-path computation primary to-hastings; secondary alt-hastings; } interface so-0/0/0; } }
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.
Surabonnement de taille de liaison LSP
Vous pouvez augmenter la bande passante réservable maximale sur la liaison et utiliser les valeurs gonflées pour la comptabilisation de la bande passante. Utilisez l’instruction subscription
pour surabonner le lien. La valeur configurée est appliquée à toutes les allocations de bande passante de type classe sur la liaison. Pour plus d’informations sur le surabonnement de taille de liaison, consultez Configuration du pourcentage d’abonnement de bande passante pour les LSP.
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.
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
:
subscription percentage;
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
, ct2
et 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 .
subscription { ct0 percentage; ct1 percentage; ct2 percentage; ct3 percentage; }
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’interfacesubscription
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 :
user@host# commit check [edit protocols rsvp interface all] 'subscription' RSVP: Must have a diffserv-te bandwidth model configured when configuring subscription per traffic class. error: configuration check-out failed
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 :user@host# commit check [edit protocols rsvp interface all] 'subscription' RSVP: Cannot configure both link subscription and per traffic class subscription. error: configuration check-out failed
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.