Itinéraires LSP
Tables de routage et MPLS
Les IGP et BGP stockent leurs informations de routage dans la table de routage inet.0, la principale table de routage IP. Si la traffic-engineering bgp commande est configurée, autorisant ainsi uniquement BGP à utiliser des chemins MPLS pour transférer le trafic, les informations sur le chemin MPLS sont stockées dans une table de routage distincte, inet.3. Seul BGP accède à la table de routage inet.3. BGP utilise à la fois inet.0 et inet.3 pour résoudre les adresses next-hop. Si la commande est configurée, permettant ainsi aux IGP d’utiliser des chemins MPLS pour transférer le trafic, les informations relatives au chemin MPLS sont stockées dans la traffic-engineering bgp-igp table de routage inet.0. Figure 1 ( et Figure 2 illustrer les tables de routage dans les deux configurations d’ingénierie du trafic.)
La table de routage inet.3 contient l’adresse hôte du routeur de sortie de chaque LSP. Cette table de routage est utilisée sur les routeurs entrants pour acheminer les paquets vers le routeur de sortie de destination. BGP utilise la table de routage inet.3 sur le routeur entrant pour résoudre les adresses de saut suivant.
MPLS gère également une table de routage de chemin MPLS (mpls.0), qui contient la liste du prochain routeur à commutation d’étiquettes dans chaque LSP. Cette table de routage est utilisée sur les routeurs de transit pour acheminer les paquets vers le routeur suivant le long d’un LSP.
En règle générale, le routeur de sortie d’un LSP ne consulte pas la table de routage mpls.0. (Ce routeur n’a pas besoin de consulter mpls.0 car l’avant-dernier routeur du LSP change l’étiquette du paquet à une valeur de 0 ou fait sauter l’étiquette.) Dans les deux cas, le routeur de sortie le transfère en tant que paquet IPv4, en consultant la table de routage IP, inet.0, pour déterminer comment transférer le paquet.
Lorsqu’un routeur de sortie de transit reçoit un paquet MPLS, les informations contenues dans le table de transfert MPLS sont utilisées pour déterminer le prochain routeur de transit dans le LSP ou pour déterminer que ce routeur est le routeur de sortie.
Lorsque BGP résout un préfixe de saut suivant, il examine les tables de routage inet.0 et inet.3 et recherche le saut suivant avec la préférence la plus faible. S’il trouve une entrée next-hop avec une préférence égale dans les deux tables de routage, BGP préfère l’entrée dans la table de routage inet.3.
En règle générale, BGP sélectionne les entrées next-hop dans la table de routage inet.3, car leurs préférences sont toujours inférieures aux préférences OSPF et IS-IS next-hop. Lorsque vous configurez des LSP, vous pouvez remplacer la préférence par défaut pour les LSP MPLS, ce qui peut modifier le processus de sélection du saut suivant.
Lorsque BGP sélectionne une entrée de saut suivant dans la table de routage inet.3, il installe ce LSP dans la table de transfert du moteur de transfert de paquets, ce qui entraîne l’entrée et le déplacement des paquets destinés à ce prochain saut le long du LSP. Si le LSP est supprimé ou échoue, le chemin est supprimé de la table de routage inet.3 et de la table de transfert, et BGP revient à l’utilisation d’un saut suivant de la table de routage inet.0.
Vue d’ensemble du reroutage rapide
Le reroutage rapide assure la redondance d’un chemin LSP. Lorsque vous activez le reroutage rapide, des détours sont précalculés et préétablis le long du LSP. En cas de défaillance du réseau sur le chemin LSP actuel, le trafic est rapidement acheminé vers l’un des détours. Figure 3 illustre un LSP allant du routeur A au routeur F, en indiquant les détours établis. Chaque détour est établi par un nœud en amont pour éviter le lien vers le nœud immédiat en aval et le nœud immédiat en aval lui-même. Chaque détour peut passer par un ou plusieurs routeurs (ou commutateurs) à commutation d’étiquettes qui ne sont pas illustrés sur la figure.
Le reroutage rapide protège le trafic contre tout point de défaillance unique entre les routeurs (ou commutateurs) entrants et sortants. En cas de défaillance dans un scénario de reroutage rapide mis à l’échelle, les équipements perdent l’accessibilité à tous les homologues connectés via la liaison défaillante. Cela entraîne une interruption du trafic, car la session BGP entre les appareils tombe en panne. S’il existe plusieurs défaillances le long d’un LSP, le reroutage rapide lui-même peut échouer. En outre, le reroutage rapide ne protège pas contre la défaillance des routeurs entrants ou sortants.
Si un nud détecte qu’une liaison en aval a échoué (à l’aide d’un mécanisme de détection de vivacité spécifique à la couche de liaison) ou qu’un nud en aval a échoué (par exemple, en utilisant le protocole RSVP neighbor hello), le nud bascule rapidement le trafic vers le détour et, en même temps, signale au routeur entrant la défaillance de la liaison ou du nud. Figure 4 illustre le détour effectué en cas d’échec de la liaison entre le routeur B et le routeur C.
Si la topologie du réseau n’est pas assez riche (c’est-à-dire qu’il n’y a pas assez de routeurs avec suffisamment de liens vers d’autres routeurs), certains détours risquent de ne pas réussir. Par exemple, le détour du routeur A vers le routeur C dans Figure 3 ne peut pas traverser la liaison A-B et le routeur B. Si un tel chemin n’est pas possible, le détour n’a pas lieu.
Notez qu’une fois que le nœud a basculé le trafic vers la déviation, il peut basculer à nouveau le trafic vers une nouvelle déviation calculée peu de temps après. En effet, l’itinéraire de détour initial n’est peut-être pas le meilleur itinéraire. Pour rendre le réacheminement aussi rapide que possible, le nœud bascule le trafic sur le détour initial sans vérifier au préalable que le détour est valide. Une fois le changement effectué, le noeud recalcule le détour. Si le noeud détermine que le détour initial est toujours valide, le trafic continue à passer par ce détour. Si le nœud détermine que le détour initial n’est plus valide, il bascule à nouveau le trafic vers un détour nouvellement calculé.
Si vous émettez show des commandes après que le noeud a basculé le trafic vers le détour initial, le noeud peut indiquer que le trafic circule toujours sur le LSP d’origine. Cette situation est temporaire et devrait se corriger rapidement.
Le temps nécessaire pour qu’un détour de réacheminement rapide prenne effet dépend de deux intervalles de temps indépendants :
Temps nécessaire pour détecter la défaillance d’un lien ou d’un nud : cet intervalle dépend fortement de la couche de liaison utilisée et de la nature de la défaillance. Par exemple, la détection des défaillances sur une liaison SONET/SDH est généralement beaucoup plus rapide que sur une liaison Gigabit Ethernet, et les deux sont beaucoup plus rapides que la détection d’une défaillance de routeur.
Temps nécessaire pour épisser le trafic sur le détour : cette opération est effectuée par le moteur de transfert de paquets, qui nécessite peu de temps pour épisser le trafic sur le détour. Le temps nécessaire peut varier en fonction du nombre de prestataires de services linguistiques qui sont transférés vers des détours.
Le reroutage rapide est un correctif à court terme visant à réduire la perte de paquets. Étant donné que le calcul des détours peut ne pas réserver suffisamment de bande passante, les détours peuvent introduire un encombrement sur les liaisons alternatives. Le routeur entrant est le seul routeur pleinement conscient des contraintes de stratégie LSP et, par conséquent, le seul routeur capable de proposer des chemins alternatifs adéquats à long terme.
Des détours sont créés à l’aide de RSVP et, comme toutes les sessions RSVP, ils nécessitent un état et une surcharge supplémentaires sur le réseau. Pour cette raison, chaque nœud établit au maximum un détour pour chaque LSP pour lequel le reroutage rapide est activé. La création de plus d’un détour pour chaque LSP augmente les frais généraux, mais ne sert à rien.
Pour réduire davantage la surcharge du réseau, chaque détour tente de revenir dans le LSP dès que possible après la défaillance du nud ou du lien. Si vous pouvez envisager un LSP qui passe par n des nœuds de routeur, il est possible de créer n – 1 des détours. Par exemple, dans , le détour tente de fusionner à nouveau dans Figure 5le LSP au niveau du routeur D au lieu du routeur E ou du routeur F. La fusion dans le LSP rend le problème d’évolutivité du détour plus facile à gérer. Si les limitations de la topologie empêchent le détour de se fondre rapidement dans le LSP, les détours fusionnent automatiquement avec les autres détours.
Configuration du reroutage rapide
Le reroutage rapide fournit un mécanisme permettant de réacheminer automatiquement le trafic sur un LSP en cas de défaillance d’un nud ou d’un lien dans un LSP, réduisant ainsi la perte de paquets transitant sur le LSP.
Pour configurer le reroutage rapide sur un LSP, incluez l’instruction fast-reroute sur le routeur entrant (ou commutateur) :
fast-reroute { (bandwidth bps | bandwidth-percent percentage); (exclude [ group-names ] | no-exclude ); hop-limit number; (include-all [ group-names ] | no-include-all); (include-any [ group-names ] | no-include-any); }
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 n’avez pas besoin de configurer le reroutage rapide sur les routeurs (ou commutateurs) de transit et de sortie du LSP. Une fois le reroutage rapide activé, le routeur entrant (ou commutateur) signale à tous les routeurs (ou commutateurs) en aval que le reroutage rapide est activé sur le LSP, et chaque routeur en aval fait de son mieux pour configurer des déviations pour le LSP. Si un routeur en aval ne prend pas en charge le reroutage rapide, il ignore la demande de configuration de détours et continue de prendre en charge le LSP. Un routeur qui ne prend pas en charge le reroutage rapide entraînera l’échec de certains détours, mais n’aura aucun impact sur le LSP.
Pour activer le reroutage rapide PFE, configurez une instruction de stratégie de routage avec l’instruction load-balance per-packet au [edit policy-options policy-statement policy-name then] niveau hiérarchique sur chacun des routeurs sur lesquels le trafic peut être rerouté. Reportez-vous également à la section Configuration de l’équilibrage de charge entre les LSP RSVP.
Par défaut, aucune bande passante n’est réservée pour le chemin réacheminé. Pour allouer de la bande passante au chemin réacheminé, incluez l’instruction ou l’instruction bandwidthbandwidth-percent . Vous ne pouvez inclure qu’une seule de ces déclarations à la fois. Si vous n’incluez ni l’instruction ni l’instruction bandwidthbandwidth-percent , le paramètre par défaut est de ne pas réserver de bande passante pour le chemin de détour.
Lorsque vous incluez l’instruction bandwidth , vous pouvez spécifier la quantité spécifique de bande passante (en bits par seconde [bps]) que vous souhaitez réserver pour le chemin de détour. Il n’est pas nécessaire que la bande passante soit identique à celle allouée pour le LSP.
Lorsque vous spécifiez un pourcentage de bande passante à l’aide de l’instruction, la bande passante du chemin de déviation est calculée en multipliant le pourcentage de bande passante par la bande passante configurée pour le LSP principal issu de l’ingénierie bandwidth-percent du trafic. Pour plus d’informations sur la configuration de la bande passante d’un LSP issu de l’ingénierie du trafic, consultez Configuration des LSP issus de l’ingénierie du trafic.
Les contraintes de limite de saut définissent le nombre de routeurs supplémentaires qu’un détour est autorisé à traverser par rapport au LSP lui-même. Par défaut, la limite de sauts est définie sur 6. Par exemple, si un LSP traverse 4 routeurs, tout détour pour le LSP peut représenter jusqu’à 10 (c’est-à-dire 4 + 6) sauts de routeur, y compris les routeurs d’entrée et de sortie.
Par défaut, un détour hérite des mêmes contraintes de groupe d’administration (coloration) que son LSP parent lorsque CSPF détermine le chemin alternatif. 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. Si vous spécifiez l’instruction include-any lors de la configuration du LSP parent, tous les liens traversés par la session secondaire doivent avoir au moins une couleur trouvée dans la liste des groupes. Si vous spécifiez l’instruction include-all lors de la configuration du LSP parent, tous les liens traversés par la session alternative doivent avoir toutes les couleurs trouvées dans la liste des groupes. Si vous spécifiez l’instruction exclude lors de la configuration du LSP parent, aucun des liens ne doit avoir une couleur trouvée dans la liste des groupes. Pour plus d’informations sur les contraintes de groupe d’administration, consultez Configuration de groupes d’administration pour les fournisseurs de services linguistiques.
Processus de fusion de détour
Cette section décrit le processus utilisé par un routeur pour déterminer le LSP à sélectionner lorsque le routeur reçoit des messages de chemin d’accès de différentes interfaces avec des objets de modèle de session et d’expéditeur identiques. Lorsque cela se produit, le routeur doit fusionner les états de chemin.
Le routeur utilise le processus suivant pour déterminer quand et comment fusionner les états de chemin :
Lorsque tous les messages de chemin n’incluent pas de reroutage rapide ou d’objet de détour, ou lorsque le routeur est la sortie du LSP, aucune fusion n’est nécessaire. Les messages sont traités conformément à l’ingénierie du trafic RSVP.
Dans le cas contraire, le routeur doit enregistrer l’état du chemin en plus de l’interface entrante. Si les messages de chemin ne partagent pas la même interface sortante et le même routeur de saut suivant, le routeur les considère comme des LSP indépendants et ne les fusionne pas.
Pour tous les messages de chemin qui partagent la même interface sortante et le même routeur next-hop, le routeur utilise le processus suivant pour sélectionner le LSP final :
Si un seul LSP provient de ce nœud, sélectionnez-le comme LSP final.
Si un seul LSP contient un objet de reroutage rapide, sélectionnez-le comme LSP final.
S’il y a plusieurs LSP et que certains d’entre eux ont un objet de détour, éliminez ceux qui contiennent un objet de détour du processus de sélection final des LSP.
S’il reste plusieurs LSP candidats finaux (c’est-à-dire qu’il y a encore des LSP de détour et des LSP protégés), sélectionnez les LSP avec des objets de reroutage rapide.
Si aucun des LSP n’a d’objets de reroutage rapide, sélectionnez ceux qui n’ont pas d’objets de détour. Si tous les LSP ont des objets de détour, sélectionnez-les tous.
Parmi les candidats LSP restants, éliminez ceux qui traversent des nœuds que les autres LSP évitent.
S’il reste encore plusieurs LSP candidats, sélectionnez celui dont la longueur de chemin d’accès ERO (Explicit Route Object) est la plus courte. Si plusieurs prestataires de services linguistiques ont la même longueur de chemin, sélectionnez-en un au hasard.
Une fois que le LSP final a été identifié, le routeur doit transmettre uniquement les messages de chemin qui correspondent à ce LSP. Tous les autres LSP sont considérés comme fusionnés à ce nœud.
Calculs de détour
Le calcul et la mise en place des déviations se font indépendamment au niveau de chaque nœud. Sur un nud, si le reroutage rapide est activé pour un LSP et qu’une liaison ou un nud en aval peut être identifié, le routeur effectue un calcul CSPF (Constrained Shortest Path First) à l’aide des informations de la base de données d’ingénierie du trafic local. Pour cette raison, les déviations dépendent de votre IGP prenant en charge les extensions d’ingénierie de trafic. Sans la base de données des aspects techniques du trafic, il est impossible d’établir des détours.
CSPF tente d’abord de trouver un chemin qui ignore le nœud en aval suivant. Toute tentative de recherche de ce chemin fournit une protection contre les défaillances en aval dans les nœuds ou les liaisons. S’il n’est pas possible de trouver un chemin d’accès par saut de nœud, CSPF tente de trouver un chemin sur un autre lien vers le nœud en aval suivant. La recherche d’un autre lien fournit une protection contre les défaillances en aval dans les liens uniquement. Les calculs de détour peuvent échouer du premier coup. En cas d’échec d’un calcul, le routeur recalcule les détours environ une fois par intervalle d’actualisation jusqu’à ce que le calcul réussisse. La métrique RSVP pour chaque détour est définie sur une valeur comprise entre 10 000 et 19 999.
Optimisation rapide de la trajectoire de reroutage
Un chemin de protection de reroutage rapide n’est pas déterministe. Le chemin de protection réel d’un nud particulier dépend de l’historique du LSP et de la topologie du réseau lorsque le chemin de reroutage rapide a été calculé. L’absence de comportement déterministe peut entraîner des difficultés opérationnelles et des chemins mal optimisés après plusieurs battements de liens dans un réseau. Même dans un petit réseau, après quelques battements de liaison, les chemins de reroutage rapide peuvent traverser un nombre arbitrairement élevé de nœuds et rester dans cet état indéfiniment. Cette méthode est inefficace et rend le réseau moins prévisible.
L’optimisation rapide du reroutage remédie à cette lacune. Il fournit un minuteur d’optimisation de chemin global, vous permettant d’optimiser tous les LSP sur lesquels le reroutage rapide est activé et sur lesquels un chemin de détour est opérationnel. La valeur de la minuterie peut être modifiée en fonction de la charge de traitement RE attendue.
L’algorithme d’optimisation de reroutage rapide est basé sur la métrique IGP uniquement. Tant que la métrique IGP du nouveau chemin est inférieure à celle de l’ancien chemin, le résultat CSPF est accepté, même si le nouveau chemin peut être plus encombré (utilisation plus élevée de la bande passante) ou traverser plus de sauts.
Conformément à la RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels, lorsqu’un nouveau chemin est calculé et accepté pour l’optimisation du reroutage rapide, le détour existant est détruit en premier, puis le nouveau détour est établi. Pour éviter les pertes de trafic, les déviations protégeant activement le trafic ne sont pas optimisées.
Configuration de l’intervalle d’optimisation pour les chemins de reroutage rapide
Vous pouvez activer l’optimisation de chemin pour le reroutage rapide en configurant le minuteur d’optimisation du reroutage rapide. Le minuteur d’optimisation déclenche un processus d’optimisation périodique qui recalcule les LSP de déviation de reroutage rapide pour utiliser les ressources réseau plus efficacement.
Pour activer l’optimisation du chemin de reroutage rapide, spécifiez le nombre de secondes à l’aide de l’option optimize-timer pour l’instruction fast-reroute :
fast-reroute seconds;
Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :
[edit protocols rsvp][edit logical-systems logical-system-name protocols rsvp]
Ajout de routes liées au LSP à la table de routage inet.3 ou inet6.3
Par défaut, une route hôte vers le routeur de sortie est installée dans la table de routage inet.3 ou inet6.3. (L’adresse de route de l’hôte est celle que vous configurez dans l’instruction to .) L’installation de la route hôte permet au BGP d’effectuer la résolution du saut suivant. Il empêche également la route hôte d’interférer avec les préfixes appris à partir de protocoles de routage dynamiques et stockés dans la table de routage inet.0 ou inet6.0.
Contrairement aux routes de la table inet.0 ou inet6.0, les routes de la table inet.3 ou inet6.3 ne sont pas copiées dans le moteur de transfert de paquets et n’entraînent donc aucune modification directe de la table de transfert système. Vous ne pouvez pas utiliser la ping commande ou traceroute via ces routes. La seule utilisation de inet.3 ou inet6.3 est de permettre à BGP d’effectuer une résolution de saut suivant. Pour examiner la table inet.3 ou inet6.3, utilisez la show route table inet.3 commande ou show route table inet6.3 .
Pour injecter des routes supplémentaires dans la table de routage inet.3 ou inet6.3, incluez l’instruction install suivante :
install { destination-prefix <active>; }
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]
Les routes spécifiées sont installées en tant qu’alias dans la table de routage lorsque le LSP est établi. L’installation de routes supplémentaires permet au BGP de résoudre les sauts suivants dans le préfixe spécifié et de diriger le trafic supplémentaire pour ces sauts suivants vers un LSP particulier.
L’inclusion de l’option avec l’instruction install installe le préfixe spécifié dans la table de active routage inet.0 ou inet6.0, qui est la table de transfert principale. Le résultat est un itinéraire qui est installé dans la table de transfert chaque fois que le LSP est établi, ce qui signifie que vous pouvez envoyer une requête ping ou tracer l’itinéraire. Utilisez cette option avec précaution, car ce type de préfixe est très similaire à une route statique.
Les routes d’alias sont utilisées comme sauts BGP next pour les routeurs dont les adresses sont multiples, ou pour les routeurs qui ne sont pas compatibles MPLS. Dans l’un ou l’autre de ces cas, le LSP peut être configuré sur un autre système compatible MPLS au sein du domaine local, qui agit alors comme un routeur de « bordure ». Le LSP se termine ensuite sur le routeur de bordure et, à partir de ce routeur, le transfert de couche 3 achemine le paquet vers le véritable routeur de saut suivant.
Dans le cas d’une interconnexion, le routeur de bordure du domaine peut agir en tant que routeur proxy et annoncer le préfixe de l’interconnexion si le routeur de bordure ne définit pas le prochain saut BGP pour lui-même.
Dans le cas d’un point de présence (POP) dont les routeurs ne prennent pas en charge MPLS, un routeur (par exemple, un routeur central) qui prend en charge MPLS peut agir comme proxy pour l’ensemble du POP et injecter un ensemble de préfixes qui couvrent le POP. Ainsi, tous les routeurs au sein du POP peuvent se présenter comme des sauts suivants BGP (IBGP) intérieurs, et le trafic peut suivre le LSP pour atteindre le routeur central. Cela signifie qu’un routage IGP normal prévaudrait dans le POP.
Vous ne pouvez pas utiliser les commandes ou sur les ping routes de la table de routage inet.3 ou traceroute inet6.3.
Pour la résolution BGP next-hop, il n’y a aucune différence si une route est dans inet.0/inet6.0 ou inet.3/inet6.3 ; L’itinéraire avec la meilleure correspondance (masque le plus long) est choisi. Parmi plusieurs itinéraires de meilleure correspondance, celui qui a la valeur de préférence la plus élevée est choisi.
L’instruction install destination-prefix active n’est pas prise en charge sur les LSP statiques. Lorsque l’instruction install destination-prefix active est configurée pour un LSP statique, les routes MPLS ne sont pas installées dans la table de routage inet.0.