Introduction
Ce document décrit le concept de convergence avec Topology Independent (TI) - Loop-Free Alternative (LFA) qui est une fonctionnalité très ciblée. Il détaille le mécanisme de convergence des chemins de politiques de routage de segment (SR) et d'ingénierie de trafic (TE) avec la protection TI-LFA en tant que sous-couche avec un schéma de topologie basé sur les exigences des réseaux XYZ.
Détection des pannes de liaison
Veuillez noter que la convergence du chemin de la stratégie SR-TE et les fonctionnalités TI-LFA sont indépendantes l'une de l'autre et fonctionnent séparément. Cependant, la fonctionnalité TI-LFA est ajoutée pour permettre une détection rapide de la défaillance du chemin de stratégie SR-TE principal et une commutation de moins de 50 ms du trafic vers le chemin de sauvegarde prédéfini dans des conditions réseau idéales. La politique SR-TE fonctionnerait parfaitement sans TI-LFA, cependant, dans ce scénario, le nombre de convergence dépendrait uniquement du protocole IGP (Interior Gateway Protocol) et serait beaucoup plus élevé que 50 ms.
Dans le scénario Link Failure, notre objectif est de maintenir le temps de convergence aussi bas que possible, ce qui minimiserait la perte de paquets pendant l'événement de liaison down/flap.
La détection d'un événement de liaison inactive au niveau du noeud de tête de réseau peut se faire principalement par les méthodes suivantes :
1. Détection au niveau de la couche physique en cas de liaisons adjacentes rompues.
2. Détection par BFD sur Bundle en cas de liaisons distantes rompues.
Dans le premier cas, la détection est plus rapide et le temps de convergence est inférieur à la seconde option, où la détection dépend de l'intervalle BFD configuré/du minuteur d'arrêt et du point réseau exact où la liaison a été interrompue. Cependant, une détection très rapide ne signifie pas nécessairement une convergence aussi rapide, car le réseau d’organisation XYZ est une structure multicouche avec un trafic de service de bout en bout qui couvre plusieurs sauts.
Étant donné que le réseau de l'organisation XYZ est contenu dans un seul AS BGP et un seul domaine IGP, ici les chemins de sauvegarde prédéfinis TI-LFA transportent immédiatement le trafic de basculement après une défaillance de liaison dans tous les scénarios et assurent une perte de paquets minimale et une couverture de préfixe complète quel que soit l'état de la topologie. Les chemins principaux/secondaires définis par la politique SR-TE peuvent mettre un certain temps à converger en raison du protocole IGP et prendre finalement le contrôle du trafic de service de bout en bout via le coeur qui peut ou ne peut pas correspondre aux chemins prédéfinis de TI-LFA.
Scénarios de convergence détaillés
Pour plus de détails, examinons l'exemple détaillé ici qui explique le chemin du trafic avec les politiques SR-TE et TI-LFA comme mécanisme de convergence du réseau d'organisation XYZ.
Exemple de configuration SR alignée sur les diagrammes de topologie :
segment-routing
traffic-eng
!
!
segment-list PrimaryPath1
index 10 mpls adjacency 10.1.11.0 --> First Hop (P1 node) of the explicit-path
index 20 mpls adjacency 10.1.3.1 --> Second Hop (P3 node) of the explicit-path
index 30 mpls adjacency 10.3.13.1 --> Third Hop (PE3 node) of the explicit-path
!
policy POL1
source-address ipv4 11.11.11.11 --> Source Node of the explicit-path
color 10 end-point ipv4 33.33.33.33 --> Destination Node of the explicit-path
candidate-paths
preference 100 --> Secondary Path taken care of dynamically by IGP TI-LFA
dynamic
metric
type igp
!
!
!
preference 200
explicit segment-list PrimaryPath1 --> Primary Explicit-Path of the SR-TE policy
!
!
Dans un scénario normal, le trafic doit passer de PE1 à PE3 via l'un des deux chemins candidats possibles PE1 > P1 > P3 > PE3
et PE1 > P2 > P4 > PE3
de la politique SR-TE, le chemin explicite principal configuré par l'administrateur avec la liste Adj (Adjacency) - SID (Segment Identifier) 10.1.11.0, 10.1.3.1, 10.3.13.1
ou le chemin dynamique secondaire déterminé par le protocole IGP concerné. L'administrateur préfère utiliser le chemin candidat principal et ne revenir au chemin secondaire que lorsque le chemin principal est en panne. Ainsi, une valeur de préférence supérieure est attribuée au chemin candidat principal qui indique un chemin préféré. Par exemple, le chemin candidat principal peut avoir une préférence de 200
et le chemin candidat secondaire a une préférence de 100
.
Figure 1 : Scénario de trafic normal SR-TE, chemin principal du candidat
Tout chemin candidat est utilisé lorsqu'il est valide, et l'accessibilité de ses SID constituants détermine le critère de validité.
Lorsque les deux chemins candidats sont valides et utilisables, la tête de réseau PE1 sélectionne le chemin de préférence supérieure et installe la liste SID de ce chemin 10.1.11.0, 10.1.3.1, 10.3.13.1
dans sa table de transfert. À tout moment, le trafic de service qui est dirigé dans cette stratégie SR est envoyé uniquement sur le chemin sélectionné, tous les autres chemins candidats dynamiques sont inactifs.
Un chemin candidat est sélectionné lorsqu'il présente la valeur de préférence la plus élevée parmi tous les chemins candidats valides de la politique SR. Le chemin choisi est également appelé « chemin actif » de la stratégie SR.
Convergence des pannes de liaison - Le chemin principal passe à l'état Down
À un moment donné, une défaillance de liaison peut se produire sur le réseau. La liaison défaillante peut être une liaison entre deux noeuds quelconques, par exemple, P1 et P3. Dès que la défaillance est détectée par tout moyen décrit au début de la section, la protection TI-LFA doit garantir que les flux de trafic sont rapidement redirigés vers le chemin de protection TI-LFA, idéalement dans un délai de 50 ms.
Notez que dans ce scénario, le chemin de sauvegarde déterminé par TI-LFA, comme illustré à la Figure 2, est différent du chemin de stratégie de sauvegarde convergente déterminé par IGP à la Figure 3. Ceci est assez normal puisque le chemin de sauvegarde Ti-LFA est localement déterminé par le noeud Point Of Local Repair (PLR) où la panne s'est produite, cependant, le chemin de sauvegarde de politique SR-TE optimisé est déterminé par la convergence IGP par le noeud de tête de réseau qui détient les décisions de politique SR-TE.
Figure 2 : Scénario de trafic de basculement via le chemin de sauvegarde TI-LFA
Le trafic continue à circuler par le chemin de protection TI-LFA jusqu'à ce que finalement, la tête de réseau PE1 apprenne par inondation IGP que le SID 10.1.3.1
de la liaison défaillante est devenu invalide. PE1 évalue ensuite la validité de la liste SID du chemin d’accès, 10.1.11.0, 10.1.3.1, 10.3.13.1
puis l’invalide en raison de la présence du SID non valide 10.1.3.1
. Simultanément, il invalide le chemin candidat et réexécute le processus de sélection de chemin de la stratégie SR-TE. PE1, par la suite, sélectionne un autre chemin candidat valide avec la valeur de préférence suivante la plus élevée et installe la liste SID 10.2.11.0, 10.2.4.1, 10.4.13.1
du nouveau chemin candidat secondaire dans la table de transfert. Cependant, ce chemin candidat secondaire est de nature dynamique, déterminé par le protocole OSPF (Open Shortest Path First) IGP, et n'a aucun contrôle administratif. Jusqu'à cette étape, le trafic circule via le chemin TI-LFA protégé ; mais après cela, il est dirigé vers le nouveau chemin secondaire préféré de la politique SR-TE.
Figure 3 : Scénario de trafic de basculement via le chemin du candidat secondaire SR-TE
Résumé des étapes:
1. Sur le point de défaillance :
- La couche 1/BFD signale le chemin principal vers FIB
- FIB envoie au matériel le chemin de sauvegarde établi avec TI-LFA
- Panne de trafic attendue :
- Liaison désactivée: ~50 ms
- Perte d'homologue BFD : temps mort BFD + ~50 ms
- L'appairage OSPF sur la liaison perdue tombe en panne
2. Tous les routeurs OSPF du domaine apprennent la perte de SID par inondation de LSA (Link State Advertisement)
3. Sur la tête de réseau SR-TE PE1 :
- Le protocole OSPF converge
- La liste SID du chemin principal de la stratégie SR-TE est invalidée
- Le chemin du candidat principal s'arrête
- La liste SID du chemin candidat secondaire est validée et devient active
- Le trafic est envoyé via un chemin secondaire sans perte de trafic de service
Re-convergence en cas de défaillance de liaison - Retour à l'état actif du chemin principal
Pendant ce temps, une fois que la liaison principale défaillante est restaurée, le chemin principal d'origine avec préférence (200) redevient valide et ainsi la tête de réseau PE1 exécute la procédure de sélection de chemin de politique SR-TE, sélectionne le chemin candidat explicite valide avec la préférence la plus élevée et met à jour sa table de transfert avec la liste SID du chemin principal d'origine. Le trafic de service qui est dirigé dans cette stratégie SR est envoyé sur le chemin d'origine à nouveauPE1 > P1 > P3 > PE3
.
Figure 4 : Scénario de reconvergence du trafic
Résumé des étapes:
1. La couche 1/BFD signale la restauration du chemin principal et OSPF est averti.
2. Le trafic est toujours transféré via le chemin candidat de sauvegarde de la stratégie SR-TE.
3. Au bout d'un certain temps, la liste SID du chemin candidat principal de la stratégie SR-TE devient valide via l'inondation OSPF LSA.
4. Le trafic est commuté du chemin candidat de sauvegarde de la stratégie SR-TE vers le chemin candidat principal de la stratégie SR-TE avec une perte de trafic nulle.
Pour conclure, ces scénarios fournissent une explication théorique du processus de convergence et des numéros de convergence idéaux. Cependant, vous devez tester les numéros de convergence réels dans les travaux pratiques qui imitent le réseau de production et la configuration aussi fidèlement que possible et déclenchent différents points de défaillance dans le réseau, ce que l'on peut prévoir.
Attention : Notez que ce document explique uniquement les scénarios de protection de liaison puisque la protection de noeud ne fonctionne pas avec les chemins explicites SR-TE si le chemin explicite défini touche des noeuds intermédiaires. Cela est dû au fait que TI-LFA prend chaque saut intermédiaire configuré comme noeud de destination et qu'en cas de défaillance de l'un de ces noeuds, il ne peut pas résoudre la destination finale. Il s'agit d'une limitation technologique qui n'est pas limitée à une plate-forme ou à une version d'image. La solution à cette limitation a été abordée dans la Partie 2 de ce document, comme indiqué dans la section Informations connexes.
Logiciels utilisés
Le logiciel utilisé pour tester et valider la solution est Cisco IOS®XR 7.3.2.
Informations connexes