Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

LSP Routes

MPLS tables de routage et de routage

Les IGP et BGP leurs informations de routage dans la table de routage inet.0, la table de routage IP principale. Si la commande est configurée, permettant ainsi à BGP d’utiliser uniquement des chemins MPLS pour le trafic de routage, les informations du chemin MPLS sont stockées dans une table de traffic-engineering bgp routage séparée, inet.3. Seule BGP accès à 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 commande est configurée, ce qui permet aux IGP d’utiliser des chemins MPLS pour le trafic de routage, les informations sur MPLS chemin sont stockées dans la table de traffic-engineering bgp-igp routage inet.0. ( Figure 1 et Figure 2 illustrez les tables de routage dans les deux configurations des ingénieries de trafic.)

Figure 1 : Tables de routage et de routage, ingénierie du trafic bgpTables de routage et de routage, ingénierie du trafic bgp

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

MPLS également une table de routage MPLS chemin (mpls.0), qui contient une liste du prochain routeur de commuté d’étiquettes dans chaque LSP. Cette table de routage est utilisée sur les routeurs de transit pour router 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 soit le label du paquet soit sur une valeur de 0, soit il poppe le label.) Dans les deux cas, le routeur de sortie le fait suivre sous la direction d’un paquet IPv4, consultant la table de routage IP inet.0, pour déterminer la façon dont il doit avancer le paquet.

Lorsqu’un routeur de transit ou de sortie reçoit un paquet MPLS, les informations du tableau 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 un préfixe du saut suivant, il examine les tables de routage inet.0 et inet.3 en cherchant le saut suivant avec la préférence la plus faible. Si elle trouve une entrée au saut suivant 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.

Figure 2 : Tables de routage et de routage, ingénierie du trafic bgp-igpTables de routage et de routage, ingénierie du trafic bgp-igp

En général, BGP sélectionne les entrées du saut suivant dans la table de routage inet.3 parce que leurs préférences sont toujours inférieures à celles de OSPF et IS-IS de saut suivant. Lorsque vous configurez les LSP, vous pouvez remplacer la préférence par MPLS des LSP, qui peut altérer le processus de sélection du saut suivant.

Lorsque BGP sélectionne une entrée vers le saut suivant dans la table de routage inet.3, elle installe ce LSP dans la table de forwarding de la moteur de transfert de paquets, ce qui permet aux paquets à destination du saut suivant d’entrer et de circuler sur le LSP. Si le LSP est supprimé ou défaie, le chemin est retiré de la table de routage inet.3 et de la table de passation, et BGP revient à utiliser le saut suivant de la table de routage inet.0.

Présentation du rerouroute rapide

Le reroutage rapide fournit une redondance pour un chemin LSP. Lorsque vous activez un reroutage rapide, les déviations sont pré-complexes et préintétablées 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 itinéraires. Figure 3 illustre un LSP du routeur A au routeur F, montrant les déviations établies. 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éviation peut passer par un ou plusieurs routeurs (ou commutateurs) à commuter d’étiquettes, qui ne sont pas indiqué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 rerouroute rapide à grande échelle, les équipements perdent leur accessibilité pour tous les pairs connectés via la liaison défagée. Ceci entraîne une interruption du trafic lorsque BGP entre les équipements s’en panne. En cas de défaillances multiples le long d’un LSP, le rerouroutement rapide lui-même peut être défaisant. En outre, le rerouroute rapide ne protège pas contre la défaillance des routeurs d’entrée ou de sortie.

Figure 3 : Détours mis en place pour un LSP à l’aide d’un rerouroutement rapideDétours mis en place pour un LSP à l’aide d’un rerouroutement 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’état de direct propres à la couche de liaison) ou une défaillance d’un nœud en aval (par exemple via le protocole RSVP Neighbor Hello), ce dernier bascule rapidement le trafic vers le déviation et signale en même temps au routeur d’entrée la liaison ou la défaillance du nœud. illustre la déviation prise lorsque la liaison entre le routeur B et le Figure 4 routeur C échoue.

Figure 4 : Déviation Après le passage du routeur B au routeur C défaînéDéviation Après le passage du routeur B au routeur C défaîné

Si la topologie réseau n’est pas suffisamment riche (il n’y a pas assez de routeurs avec des liaisons suffisantes vers d’autres routeurs), certaines déviations pourraient ne pas réussir. Par exemple, le chemin d’accès entre le routeur A et le routeur C ne peut pas traverser les Figure 3 liaisons A-B et B. Si un tel chemin n’est pas possible, le déviation ne se produit pas.

Notez qu’une fois le trafic de commuté passé au détour, ce dernier peut être de nouveau dévié vers un nouveau détour calculé peu après. Car le chemin de déviation initial n’est peut-être pas la meilleure. Pour faciliter le réroutage le plus rapidement possible, le nœud commute le trafic sur le chemin initial, sans avoir à vérifier au premier abord que ce détour est valide. Une fois le commutateur mis en place, le nœud recalcule la déviation. Si le nœud détermine que le chemin initial reste valide, le trafic continue de circuler sur ce chemin. 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 informatique.

Remarque :

Si vous émettrez des commandes après que le nœud a commuté le trafic vers le chemin initial, il peut indiquer que le trafic circule toujours sur le show LSP d’origine. Cette situation est temporaire et doit être corriger rapidement.

Le temps nécessaire à un déroutage rapide pour prendre effet est fonction de deux intervalles différents:

  • Temps de détection d’une défaillance de liaison ou de nœud. Cet intervalle dépend grandement de la couche de liaison en cours d’utilisation et de la nature de la défaillance. Par exemple, la détection de défaillances sur une liaison SONET/SDH est généralement bien plus rapide que sur une liaison Gigabit Ethernet, et ces deux sont bien plus rapides que la détection d’une défaillance d’un routeur.

  • Temps nécessaire à l’application du trafic sur le détour; cette opération est effectuée par le moteur de transfert de paquets, qui ne requiert que peu de temps pour spliquer le trafic vers le détour. La durée requise peut varier en fonction du nombre de LSP commutés vers des déviations.

Le rerouroute rapide est un correctif à court terme qui réduit les pertes de paquets. Les déviations informatiques ne réservent pas nécessairement de bande passante, ce qui risque de congestionner les liaisons alternatives. Le routeur d’entrée est le seul à prendre entièrement en compte les contraintes des stratégies LSP et donc le seul à trouver des chemins alternatifs adaptés à long terme.

Les déviations sont créées par l’utilisation de RSVP et, comme toutes les sessions RSVP, elles nécessitent un état supplémentaire et des frais généraux sur le réseau. C’est pour cette raison que chaque nœud établit au mieux un détour pour chaque LSP activé. La création de plusieurs déviations pour chaque LSP augmente les coûts, mais ne sert à rien d’pratique.

Pour réduire davantage les coûts de réseau, chaque déviation tente de revenir au LSP le plus vite possible après l’échec du nœud ou de la liaison. Si vous pouvez envisager un LSP qui voyage via des n nodes de routeur, il est possible de créer des n – 1 déviations. Par exemple, dans le « routeur E » ou le « Routeur F ». L’itinéraire tente de revenir au LSP au lieu du routeur E ou F. La fusion avec le LSP facilite la gestion du problème d’évolutivité du Figure 5 détour. Si les limites de topologie empêchent le déviation de se fusionner rapidement dans le LSP, les déviations se fondent automatiquement sur d’autres déviations.

Figure 5 : Détours Fusionging into Other DetoursDétours Fusionging into Other Detours

Configuration d’un reroutage rapide

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

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

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

Il n’est pas nécessaire de configurer un rerouroute rapide sur les routeurs (ou commutateurs) de transit et de sortie du LSP. Une fois le rerouroute rapide activé, le routeur d’entrée (ou commutateur) signale tous les routeurs (ou commutateurs) en aval qui sont activés sur le LSP. Chaque routeur en aval fait de son mieux pour mettre en place des déviations pour le LSP. Si un routeur en aval ne prend pas en charge le rerouroute rapide, il ignore la demande de mise en place des déviations et continue à prendre en charge le LSP. Un routeur qui ne prend pas en charge le rerouroute rapide provoque la panne de certains des itinéraires, mais n’a autrement aucun impact sur le LSP.

Remarque :

Pour activer un reroutage rapide du PFE, configurez une déclaration de stratégie de routage avec l’instruction au niveau de la hiérarchie sur chacun des routeurs sur lequel le trafic peut load-balance per-packet[edit policy-options policy-statement policy-name then] être redirigé. Voir également Configurer l’équilibrage de charge sur les LSP RSVP.

Par défaut, aucune bande passante n’est réservée au chemin redirigé. Pour allouer de la bande passante au chemin redirigé, inclure bandwidth l’énoncé ou bandwidth-percent l’énoncé. Vous ne pouvez inclure qu’un de ces énoncés à la fois. Si vous n’avez pas inclure l’instruction ou l’énoncé, le paramètre par défaut ne doit pas réserver de bande passante bandwidth pour le chemin de bandwidth-percent déviation.

Lorsque vous ajoutez l’instruction, vous pouvez spécifier la quantité de bande passante spécifique (en bits par seconde [bps]) que vous devez réserver pour le bandwidth chemin de déviation. La bande passante ne doit pas être identique à celle allouée au LSP.

Lorsque vous spécifiez un pourcentage de bande passante à l’aide de l’énoncé, la bande passante de déviation est calculée en multipliant le pourcentage de bande passante par la bande passante configurée pour le bandwidth-percent LSP trafic principal. Pour savoir comment configurer la bande passante pour un LSP conçu pour le trafic, consultez configuring Traffic-Engineered LSP.

Par rapport au LSP lui-même, les contraintes liées à la limitation du saut définissent le nombre de routeurs par itinéraire autorisés. Par défaut, la limite de saut est définie sur 6. Par exemple, si un LSP traverse 4 routeurs, il peut y avoir jusqu’à 10 sauts de routeur (4 + 6), y compris les routeurs d’entrée et de sortie.

Par défaut, un détour hérite des mêmes contraintes administratives (coloration) par groupe que son LSP parent lorsque CSPF détermine le chemin alternatif. Les groupes administratifs, également appelés coloration de liens ou classe de ressources, se font attribuer manuellement des attributs décrivent la « couleur » des liens, de telle manière que les liens avec la même couleur appartiennent conceptuellement à la même classe. Si vous spécifiez l’instruction lors de la configuration du LSP parent, toutes les liaisons traversant la session alternative doivent avoir au moins une couleur dans la liste des include-any groupes. Si vous spécifiez l’énoncé lors de la configuration du LSP parent, toutes les liaisons traversant la session alternative doivent être toutes les couleurs répertoriées dans la liste des include-all groupes. Si vous spécifiez l’instruction lors de la configuration du LSP parent, aucune des liaisons ne doit avoir de couleur dans la exclude liste des groupes. Pour plus d’informations sur les contraintes des groupes administratifs, consultez la procédure Configuring Administrative Groups for LSP.

Détour du processus de fusion

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 d’interfaces différentes, avec des objets de modèles de session et d’expéditeur identiques. Dans ce cas, le routeur doit fusionner les états du chemin.

Le routeur utilise le processus suivant pour déterminer quand et comment fusionner les états des chemins:

  • Lorsque tous les messages de chemin n’incluent pas de reroutage rapide ou d’objet de déviation, ou lorsque le routeur constitue la sortie du LSP, aucune fusion n’est requise. Les messages sont traitées conformément aux ingénieries 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 routeur de saut suivant, le routeur les considère comme des LSP indépendants et ne les fusionnera pas.

  • Pour tous les messages de chemin qui partagent la même interface sortante et un routeur de saut suivant, le routeur utilise le processus suivant pour sélectionner le LSP final:

    • Si un seul LSP est à l’origine de ce nœud, sélectionnez-le comme LSP final.

    • Si un seul LSP contient un objet de rerouroute rapide, sélectionnez-le comme LSP final.

    • S’il y a plusieurs LSP dont certains sont avec un objet de déviation, éliminez ceux contenant un objet de déviation du processus de sélection LSP final.

    • Si plusieurs derniers candidats au LSP demeurent (c’est-à-dire qu’il existe encore des LSP détournant et protégés), sélectionnez les LSP avec des objets de rerouroute rapide.

    • Si aucun LSP n’a d’objets à rediriger rapidement, sélectionnez ceux sans objet de déviation. Si tous les LSP ont des objets de déviation, sélectionnez-les tous.

    • Sur les candidats LSP restants, éliminez de tout facteur ceux qui traversent des nodes que les autres LSP évitent.

    • Si plusieurs LSP candidats demeurent, sélectionnez le chemin ERO avec l’objet de route explicite le plus court. Si plusieurs LSP ont la même longueur de chemin, sélectionnez-en un de manière aléatoire.

  • Une fois le LSP final identifié, le routeur doit transmettre uniquement les messages de chemin correspondant à ce LSP. Tous les autres LSP sont alors fusionner au niveau de ce nœud.

Déviation des calculs

Le calcul et la configuration des déviations sont effectués indépendamment au niveau de chaque nœud. Sur un nœud, si un LSP dispose d’un rerouillon rapide et qu’une liaison ou un nœud en aval est identifié, le routeur effectue un calcul CSPF (Constrained Shortest Path First) à l’aide des informations de la base de données locale des ingénieries de trafic. Pour cette raison, les déviations s’appuient sur vos IGP des extensions techniques du trafic. Sans la base de données des ingénieries de trafic, les déviations ne peuvent pas être établies.

CSPF tente initialement de trouver un chemin qui ignore le prochain nœud en aval. En essayant de trouver ce chemin, vous pouvez vous protéger contre les pannes en aval, dans les liaisons ou les niveaux de liaison. Si un chemin de saut de nœud n’est pas disponible, CSPF tente de trouver un chemin sur une liaison alternative vers le prochain nœud en aval. La tentative de trouver une liaison alternative offre une protection contre les pannes en aval uniquement dans les liaisons. Il se peut que les calculs Detour ne réussissent pas la première fois. En cas d’échec de calcul, le routeur recalcule les déviations environ une fois chaque intervalle de mise à niveau jusqu’à ce que le calcul réussisse. La mesure RSVP pour chaque déviation est définie sur une valeur de l’échelle de 10 000 à 19 999.

Optimisation rapide des chemins de reroutisation

Un chemin de protection rapide est nondéterminé. Le chemin de protection réel d’un nœud particulier dépend de l’historique du LSP et de la topologie réseau au moment du calcul du chemin de rerouroute rapide. Le manque de comportement déterministe peut entraîner des difficultés opérationnelles et des chemins mal optimisés après avoir passé de multiples liaisons dans un réseau. Même dans un petit réseau, après quelques liaisons, les chemins de réacheminer rapide peuvent traverser un nombre extrêmement important de nodes, et peuvent rester indéfiniment dans cet état. Cette situation est inefficace et rend le réseau moins prévisible.

L’optimisation rapide du rerouroute résout cette lacune. Il fournit un système global d’optimisation des chemins, qui vous permet d’optimiser tous les LSP qui disposent d’un rerouroute rapide et d’un chemin de déviation en cours d’exécution. La valeur du délai de traitement peut être variable en fonction de la charge de traitement du re.

L’algorithme d’optimisation du rerouroute rapide est basé IGP mesure uniquement. Tant que la métrique IGP du nouveau chemin est inférieure à celle de l’ancien chemin, le résultat du CSPF est accepté, même si le nouveau chemin est plus encombré (utilisation plus élevée de la bande passante) ou traverse plus de sauts.

Conformément à la RFC 4090, les extensions de rerouroute rapide vers RSVP-TEpour tunnels LSP , lorsqu’un nouveau chemin est calculé et accepté pour une optimisation de reroutage rapide, le détour existant est d’abord détruite, puis le nouveau chemin est établi. Pour éviter les pertes de trafic, les déviations qui protègent activement le trafic ne sont pas optimisées.

Configuration de l’intervalle d’optimisation pour les chemins de réachemination rapide

Vous pouvez activer l’optimisation des chemins pour un reroutage rapide en configurant le routeur à reroutage rapide. Le routeur d’optimisation déclenche un processus d’optimisation périodique qui recalcule les déviations rapides des LSP afin d’utiliser les ressources réseau plus efficacement.

Pour permettre l’optimisation rapide des chemins de redirigement, spécifiez le nombre de secondes à l’aide de l’option optimize-timer pour fast-reroute l’énoncé:

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

  • [edit protocols rsvp]

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

Ajout de routes LSP à la table de routage inet.3 ou inet6.3

Par défaut, un routeur hôte vers le routeur de sortie est installé dans la table de routage inet.3 ou inet6.3. (L’adresse de route hôte est celle que vous configurez dans to l’instruction.) L’installation de la route hôte permet BGP résolution du saut suivant. Elle empêche également la route hôte d’gêner les préfixes issus des protocoles de routage dynamique 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 sur le moteur de transfert de paquets. Par conséquent, elles ne provoquent aucune modification de la table de passation du système directement. Vous ne pouvez pas utiliser la ping ou la commande via ces traceroute routes. La seule utilisation d’inet.3 ou inet6.3 consiste à autoriser BGP résolution du saut suivant. Pour examiner le tableau inet.3 ou inet6.3, utilisez show route table inet.3 la ou la show route table inet6.3 commande.

Pour injecter des routes supplémentaires dans la table de routage inet.3 ou inet6.3, ajoutez install l’instruction suivante:

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

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 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’option avec l’instruction installe le préfixe spécifié dans la table de activeinstall routage inet.0 ou inet6.0, qui est la table de routage principale. Il en résulte un routeur installé dans la table de forwarding à chaque fois que le LSP est établi, ce qui signifie que vous pouvez ping ou suivre la route. Utilisez cette option avec soin, car ce type de préfixe est très similaire à une route statique.

Vous utilisez des routes sous forme d’alias pour les routeurs dont plusieurs adresses sont utilisées BGP sauts suivants, ou pour les routeurs non MPLS capacité. Dans l’un ou l’autre de ces cas, le LSP peut être configuré sur un autre MPLS au sein du domaine local, qui agit alors comme un routeur de « bordure ». Le LSP termine alors sur le routeur de bordure et, à partir de ce routeur, le forwarding de couche 3 prend le paquet vers le vrai routeur du saut suivant.

Dans le cas d’une interconnexion, le routeur de bordure du domaine peut jouer le rôle de routeur proxy et peut promouvoir le préfixe de l’interconnexion si le BGP routeur de bordure ne paramètre pas le saut suivant vers lui-même.

Dans le cas d’un point de présence (POP) ne prenons pas en charge MPLS, un routeur (par exemple un routeur central) qui prend en charge MPLS peut agir comme proxy pour l’ensemble des 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 BGP intérieures (IBGP) dans les sauts suivants, et le trafic peut suivre le LSP pour atteindre le routeur central. Autrement dit, le routage IGP prévaloir au sein du POP.

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

Pour BGP résolution du saut suivant, cela ne fait aucune différence, que la route soit inet.0/inet6.0 ou inet.3/inet6.3 ; la meilleure correspondance (masque le plus long) est choisie. Parmi les meilleurs trajets possibles, celui qui a la valeur de préférence la plus élevée est choisi.

Remarque :

install destination-prefix activeL’énoncé n’est pas pris en charge sur les LSP statiques. Lorsque l’instruction est configurée pour un LSP statique, les routes de MPLS ne sont pas installées dans la table de install destination-prefix active routage inet.0.