LSP Routes

Les IGP et BGP stockent leurs informations de routage dans la table de routage inet.0, la table de routage IP principale. Si la traffic-engineering bgp commande est configurée, permettant ainsi uniquement à BGP d’utiliser des chemins MPLS pour le transfert du 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 du saut suivant. Si la traffic-engineering bgp-igp commande est configurée, permettant ainsi aux IGP d’utiliser des chemins MPLS pour le transfert du trafic, les informations sur le chemin MPLS sont stockées dans la table de routage inet.0. (Figure 1 et Figure 2 illustrer les tables de routage dans les deux configurations techniques de trafic.)

Figure 1 : Tables de routage et de transfert, bgp d’ingénierie du trafic

La table de routage inet.3 contient l’adresse d’hôte du routeur sortant de chaque LSP. Cette table de routage est utilisée sur les routeurs entrants pour acheminer les paquets vers le routeur sortant de destination. BGP utilise la table de routage inet.3 sur le routeur entrant pour aider à résoudre les adresses du saut suivant.

MPLS gère également une table de routage de chemins MPLS (mpls.0), qui contient une liste du routeur à commutation d’étiquettes suivant 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 sortant 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 modifie le label du paquet à une valeur de 0 ou l’effrence.) Dans les deux cas, le routeur sortant le transfère en tant que paquet IPv4, consultant la table de routage IP inet.0 pour déterminer comment transférer le paquet.

Lorsqu’un routeur de transit ou de sortie reçoit un paquet MPLS, les informations de la 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 à la fois les tables de routage inet.0 et inet.3, en recherchant le saut suivant avec la préférence la plus faible. S’il trouve une entrée de saut suivant avec une préférence égale dans les deux tables de routage, BGP préfère l’entrée de la table de routage inet.3.

Figure 2 : Tables de routage et de transfert, bgp-igp

En règle générale, BGP sélectionne les entrées de saut suivant dans la table de routage inet.3, car leurs préférences sont toujours inférieures aux préférences OSPF et IS-IS du saut suivant. Lorsque vous configurez les 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 permet aux paquets destinés à ce saut suivant d’entrer et de voyager 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.

Le reroutage rapide assure la redondance d’un chemin LSP. Lorsque vous activez le reroutage rapide, les détours sont précomputés et pré-établi 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 du routeur A au routeur F, montrant les détours établis. Chaque déviation est établie par un nœud en amont pour éviter la liaison vers le nœud en aval immédiat et le nœud en aval immédiat lui-même. Chaque détour peut passer par un ou plusieurs routeurs (ou commutateurs) à commutation d’étiquettes qui ne sont pas représentés sur la figure.

Le reroutage rapide protège le trafic contre tout point de défaillance unique entre les routeurs (ou commutateurs d’entrée et de sortie). En cas de défaillance dans un scénario de reroutage rapide à l’échelle, les équipements perdent l’accessibilité à tous les pairs connectés via la liaison défaillante. Cela entraîne une interruption du trafic, à mesure que la session BGP entre les équipements tombe en panne. S’il y a 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 les défaillances des routeurs entrants ou sortants.

Figure 3 : Déviations établies pour un LSP à l’aide d’un reroutage rapide

Si un nœud détecte une défaillance d’une liaison en aval (à l’aide d’un mécanisme de détection de l’liveness spécifique à la couche de liaison) ou qu’un nœud en aval a échoué (par exemple, en utilisant le protocole RSVP neighbor hello), le nœud bascule rapidement le trafic vers le détour et, en même temps, signale au routeur d’entrée la liaison ou la défaillance du nœud. Figure 4 illustre le détour effectué lorsque la liaison entre le routeur B et le routeur C échoue.

Figure 4 : Détour après l’échec de la liaison du routeur B au routeur C

Si la topologie du réseau n’est pas assez riche (il n’y a pas assez de routeurs avec suffisamment de liaisons vers d’autres routeurs), certains des détours pourraient ne pas réussir. Par exemple, le détour du routeur A vers le routeur C ne Figure 3 peut pas passer par 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 changé le trafic vers le détour, il peut basculer à nouveau le trafic vers un nouveau détour calculé peu de temps après. En effet, le chemin de détour initial n’est peut-être pas le meilleur itinéraire. Pour accélérer le routage le plus rapidement possible, le nœud bascule le trafic sur le détour initial sans vérifier au préalable la validité du détour. Une fois le commutateur effectué, le nœud recompute le détour. Si le nœud détermine que le détour initial est toujours valable, le trafic continue de 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 nouveau détour calculé.

Le temps nécessaire pour qu’un détour à reroutage rapide prenne effet dépend de deux intervalles de temps indépendants :

• Temps de détection d’une défaillance de liaison ou de nœud : cet intervalle dépend grandement 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 ne demande que peu de temps pour épisser le trafic sur le détour. Le temps nécessaire peut varier en fonction du nombre de LSP passés aux détours.

Le reroutage rapide est un correctif à court terme visant à réduire la perte de paquets. Parce que le calcul de détour peut ne pas réserver suffisamment de bande passante, les détours risquent d’engorger les liaisons alternatives. Le routeur entrant est le seul à être pleinement conscient des contraintes de stratégie LSP et, par conséquent, est le seul à pouvoir proposer des chemins alternatifs appropriés à long terme.

Les détours sont créés à l’aide de RSVP et, comme toutes les sessions RSVP, ils nécessitent un état et des coûts supplémentaires dans le réseau. Pour cette raison, chaque nœud établit au plus un détour pour chaque LSP dont le reroutage rapide est activé. Créer plus d’un détour pour chaque LSP augmente les coûts, mais ne sert à rien.

Pour réduire davantage les coûts réseau, chaque détour tente de revenir au LSP dès que possible après l’échec du nœud ou de la liaison. 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 Figure 5, le détour tente de revenir dans le LSP au niveau du routeur D au lieu de celui du routeur E ou du routeur F. La fusion dans le LSP rend le problème d’évolutivité de détour plus facile à gérer. Si les limites de topologie empêchent le détour de revenir rapidement dans le LSP, les détours fusionnent automatiquement avec d’autres détours.

Figure 5 : Détours fusionnant dans d’autres détours

Le reroutage rapide fournit un mécanisme permettant de rediriger automatiquement le trafic sur un LSP en cas de défaillance d’un nœud ou d’une liaison dans un LSP, réduisant ainsi la perte de paquets circulant sur le LSP.

Pour configurer un reroutage rapide sur un LSP, incluez l’instruction fast-reroute sur le routeur d’entrée (ou commutateur) :

Vous pouvez inclure cette déclaration 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 un reroutage rapide sur les routeurs (ou commutateurs) de transit et de sortie du LSP. Une fois le reroutage rapide activé, le routeur d’entrée (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 des déviations et continue de prendre en charge le LSP. Un routeur qui ne prend pas en charge le reroutage rapide causera l’échec de certains détours, mais sans impact sur le LSP.

Par défaut, aucune bande passante n’est réservée au chemin redirigé. Pour allouer de la bande passante au chemin redirigé, incluez l’instruction bandwidth ou l’instruction bandwidth-percent . Vous ne pouvez inclure qu’une seule de ces déclarations à la fois. Si vous n’incluez pas l’instruction bandwidth ou l’instruction bandwidth-percent , le paramètre par défaut est de ne pas réserver la bande passante au 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. La bande passante n’a pas besoin d’être identique à celle allouée pour le LSP.

Lorsque vous spécifiez un pourcentage de bande passante à l’aide de l’instruction bandwidth-percent , la bande passante du chemin de détour est calculée en multipliant le pourcentage de bande passante par la bande passante configurée pour le LSP principal conçu par le trafic. Pour plus d’informations sur la configuration de la bande passante d’un LSP conçu pour le trafic, voir Configuration des LSP conçus par le trafic.

Les limites de sauts définissent le nombre de routeurs autorisés à traverser par un détour par rapport au LSP lui-même. Par défaut, la limite de saut est définie à 6. Par exemple, si un LSP traverse 4 routeurs, tout détour pour le LSP peut être jusqu’à 10 (c’est-à-dire 4 + 6) sauts de routeur, y compris les routeurs entrants et sortants.

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 administratifs, également connus sous le nom de coloration des liens ou de classe de ressources, sont assignés manuellement des attributs qui décrivent la « couleur » des liaisons, de sorte que les liaisons 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, toutes les liaisons traversées par l’autre session doivent avoir au moins une couleur dans la liste des groupes. Si vous spécifiez l’instruction include-all lors de la configuration du LSP parent, toutes les liaisons traversées par l’autre session 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, aucune des liaisons ne doit avoir de couleur dans la liste des groupes. Pour plus d’informations sur les contraintes des groupes administratifs, voir Configuration des groupes d’administration pour les LSP.

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 provenant de différentes interfaces avec des objets de session et de modèle 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 ne comprennent 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 selon l’ingénierie de trafic RSVP.

• Sinon, 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 de saut suivant, 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 reroutement rapide, sélectionnez-le comme LSP final.

  • S’il existe plusieurs LSP et que certains d’entre eux ont un objet de détour, éliminez ceux contenant un objet de détour du processus de sélection LSP final.

  • S’il reste plusieurs candidats LSP finaux (c’est-à-dire qu’il y a encore à la fois des déviations 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 routage rapide, sélectionnez-les sans objet de détour. Si tous les LSP ont des objets de détour, sélectionnez-les tous.

  • Parmi les candidats LSP restants, éliminez de la considération ceux qui traversent les nœuds que les autres LSP évitent.

  • S’il reste plusieurs LSP candidats, sélectionnez celui dont la longueur de chemin d’objet de routage explicite (ERO) est la plus courte. Si plusieurs LSP ont la même longueur de chemin, sélectionnez-en un au hasard.

• Une fois le dernier LSP identifié, le routeur doit transmettre uniquement les messages de chemin correspondant à ce LSP. Tous les autres LSP sont considérés comme fusionnés au niveau de ce nœud.

Le calcul et la configuration des déviations se font indépendamment au niveau de chaque nœud. Sur un nœud, si le réacheminement rapide d’un LSP est activé et si un lien ou un nœud en aval peut être identifié, le routeur effectue un calcul CSPF (Constrained Shortest Path First) à l’aide des informations contenues dans la base de données d’ingénierie du trafic local. Pour cette raison, les détours s’appuient sur votre IGP prenant en charge les extensions techniques de trafic. Sans la base de données d’ingénierie du trafic, il est impossible d’établir des déviations.

CSPF tente d’abord de trouver un chemin qui saute le nœud en aval suivant. Essayer de trouver ce chemin offre une protection contre les défaillances en aval dans les nœuds ou les liaisons. Si un chemin d’saut de nœud n’est pas disponible, CSPF tente de trouver un chemin sur une autre liaison vers le nœud en aval suivant. La tentative de trouver une autre liaison fournit une protection contre les défaillances en aval dans les liaisons uniquement. Les calculs de détour pourraient ne pas réussir la première fois. En cas d’échec d’un calcul, le routeur effectue des déviations environ une fois par intervalle de rafraîchissement jusqu’à ce que le calcul soit réussi. La métrique RSVP pour chaque détour est définie sur une valeur comprise entre 10 000 et 19 999.

Un chemin de protection contre le reroutage rapide n’est pas déterministe. Le chemin de protection réel d’un nœud 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 volets de liaison dans un réseau. Même dans un petit réseau, après quelques volets de liaison, les chemins de reroutage rapide peuvent traverser un grand nombre arbitrairement important de nœuds et peuvent rester dans cet état indéfiniment. C’est inefficace et rend le réseau moins prévisible.

L’optimisation rapide du reroutage répond à cette lacune. Il fournit un timer d’optimisation des chemins global, ce qui vous permet d’optimiser tous les LSP qui ont activé le reroutage rapide et un chemin de déviation opérationnel. La valeur du timer peut varier en fonction de la charge de traitement rer attendue.

L’algorithme d’optimisation du reroutage rapide est basé uniquement sur la métrique IGP. 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 traverse plus de sauts.

Conformément à la RFC 4090, Fast Reroutage Extensions to RSVP-TE pour les tunnels LSP, lorsqu’un nouveau chemin est calculé et accepté pour une optimisation de reroutage rapide, le détour existant est d’abord détruit, puis le nouveau détour est établi. Pour éviter les pertes de trafic, les détours qui protègent activement le trafic ne sont pas optimisés.

Vous pouvez activer l’optimisation des chemins pour un reroutage rapide en configurant le timer d’optimisation de reroutage rapide. Le timer d’optimisation déclenche un processus d’optimisation périodique qui permet aux LSP de déviation rapide de reroutage d’utiliser les ressources réseau plus efficacement.

Pour optimiser rapidement les chemins de reroutage, spécifiez le nombre de secondes à l’aide de l’option optimize-timer pour l’énoncé fast-reroute :

Vous pouvez inclure cette déclaration aux niveaux hiérarchiques suivants :

• [edit protocols rsvp]

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

Par défaut, un routage hôte vers le routeur sortant est installé 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 du routage hôte permet à BGP d’effectuer la résolution du saut suivant. Il empêche également le routage hôte d’interférer avec les préfixes appris par les 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 aucun changement directement dans la table de transfert du système. Vous ne pouvez pas utiliser la ou traceroute la ping commande via ces routes. La seule utilisation pour inet.3 ou inet6.3 est de permettre à BGP d’effectuer une résolution du 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 :

Vous pouvez inclure cette déclaration 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 sous forme d’alias dans la table de routage lorsque le LSP est établi. L’installation de routes supplémentaires permet à BGP de résoudre les sauts suivants au sein du préfixe spécifié et de diriger le trafic supplémentaire pour ces sauts suivants vers un LSP particulier.

L’inclusion de l’option active avec l’instruction install installe le préfixe spécifié dans la table de routage inet.0 ou inet6.0, qui est la table de transfert principale. Le résultat est un routage installé dans la table de transfert à chaque fois que le LSP est établi, ce qui signifie que vous pouvez ping ou tracer le routage. Utilisez cette option avec soin, car ce type de préfixe est très similaire à un routage statique.

Vous utilisez des routes d’alias pour les routeurs dont plusieurs adresses sont utilisées comme sauts suivants BGP, 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 MPLS dans le 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 amène le paquet vers le vrai routeur de saut suivant.

Dans le cas d’une interconnexion, le routeur de bordure du domaine peut faire office de routeur proxy et peut annoncer le préfixe de l’interconnexion si le routeur de bordure ne fixe pas lui-même le saut suivant BGP.

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 un proxy pour l’ensemble du POP et peut injecter un ensemble de préfixes qui couvrent le POP. Ainsi, tous les routeurs du POP peuvent se présenter comme des sauts suivants BGP (IBGP), et le trafic peut suivre le LSP pour atteindre le routeur central. Cela signifie que le routage IGP normal prévaudrait dans le POP.

Vous ne pouvez pas utiliser les pingtraceroute commandes sur les routes de la table de routage inet.3 ou inet6.3.

Pour la résolution du saut suivant BGP, il n’y a aucune différence qu’une route soit dans inet.0/inet6.0 ou inet.3/inet6.3 ; la route avec la meilleure correspondance (masque le plus long) est choisie. Parmi plusieurs routes de correspondance optimale, celle qui a la valeur de préférence la plus élevée est choisie.