-
8/19/2019 Te7585 Haute Disponibilite Dans Les Reseaux IP
1/15
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copieest strictement interdite. – © Editions T.I. TE 7 585 – 1
T
E
7
5 8 5
1 1 - 2 0 0 7
Haute disponibilitédans les réseaux IP
par Sarah NATAF
et Bruno DECRAENEIngénieurs d’études, routage IP/MPLS, France Télécom R&D
i à l’origine le protocole IP a été conçu pour fournir des services de type « best effort », les réseaux IP représentent désormais une part importante
des infrastructures de télécommunications et ont vocation à transporter de nombreux services avec leurs contraintes de disponibilité (applications dis- tantes, voix, vidéo, télévision, etc.).
Les réseaux IP peuvent être impactés par des incidents, susceptibles de réduire leur disponibilité, tels que des pannes matérielles , la perte de liens de transmission , des bugs logiciels ou des opérations de maintenance . Des solutions permettent cependant de réduire les impacts de ces incidents sur le trafic. Ce dossier se propose de décrire les technologies permettant d’assurer les fonctions de haute disponibilité « High Availability » dans les réseaux IP/ MPLS ainsi que leur implémentation sur les équipements.
1. Contexte et définitions ........................................................................... TE 7 585 - 2
1.1 Définition de la disponibilité ....................................................................... — 2
1.2 Comment améliorer la disponibilité ? ........................................................ — 2
1.3 Taxonomie des pannes ............................................................................... — 3
2. Diminution du MTTR : reroutage ......................................................... — 3
2.1 Architecture fonctionnelle d’un routeur..................................................... — 3
2.2 Temps de convergence du routage............................................................ — 4
2.3 Détection rapide ........................................................................................... — 5
2.4 Convergence « rapide »............................................................................... — 5
2.5 Protection locale........................................................................................... — 6
3. Augmentation du MTTF – Haute disponibilité . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. — 6
3.1 Contraintes de haute disponibilité au niveau du plan de transfertet Non Stop Forwarding .............................................................................. — 7
3.2 Contraintes de haute disponibilité au niveaudu plan de commande................................................................................. — 7
3.3 Capacité NSR ou Non Stop Routing .......................................................... — 7
3.4 Extensions GR ou Graceful Restart ........................................................... — 7
3.5 Protocoles multicast .................................................................................... — 12
4. Opérations de maintenance dans les réseaux IP .. ... .. .. .. ... .. .. ... .. .. .. .. — 124.1 Maintenances logicielles avec continuité de service ................................ — 12
4.2 Maintenances matérielles avec interruption de service........................... — 13
5. Conclusion.................................................................................................. — 13
Pour en savoir plus ......................................................................................... Doc. TE 7 585
S
-
8/19/2019 Te7585 Haute Disponibilite Dans Les Reseaux IP
2/15
HAUTE DISPONIBILITÉ DANS LES RÉSEAUX IP
____________________________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copieest strictement interdite. – © Editions T.I.TE 7 585 – 2
Abréviations
AS Autonomous System
ASIC Application Specific Integrated Circuit
BFD Bidirectional Forwarding Detection
BGP Border Gateway Protocol
COS Class Of Service
EGP External Gateway Protocol
FEC Forwarding Equivalence Class
FIB Forwarding Information Base
FT Fault Tolerance
GR Graceful RestartHA High Availability
IETF Internet Engineering Task Force
IGP Interior Gateway Protocol
IS-IS Intermediate System to Intermediate System
ISSU In-Service Software Upgrades
LDP Label Distribution Protocol
LER Label Edge Router
LFIB Label Forwarding Information Base
LIB Label Information Base
LRDI Line Remote Indication Defect
LSA Link State Advertisement
LSP Labeled Switched Path (MPLS)
LSP Link State Packet (IS-IS)
LSR Label Switch Router
MP-BGP Multi Protocol Extensions for BGP 4
MPLS Multi Protocol Label SwitchingArchitecture
MTBF Mean Time Between Failure
MTTF Mean Time To Failure
MTTR Mean Time To Repair
NSF Non Stop Forwarding
NSR Non Stop Routing
OSPF Open Shortest Path First
PE Provider Edge
QOS Quality Of Service
RIB Routing Information Base
RIP Routing Information Protocol
RP Route Processor
RSVP-TE Resource Reservation Protocole-TrafficEngineering
SPF Shortest Path First
TLV Type Length Value
VPN Virtual Private Network
VRF VPN Routing and Forwarding
1. Contexte et définitions
1.1 Définition de la disponibilité
Les objectifs de disponibilité sont typiquement spécifiés sousforme de fraction décimale telle que 0,999 99 ou parfois en échellelogarithmique appelée « neuf » et qui correspond globalement aunombre de neuf suivant la virgule, tel que cinq neuf pour une dis-ponibilité de 0,999 99 (tableau 1).
1.2 Comment améliorer la disponibilité ?
La disponibilité étant égale à MTTF/(MTTF + MTTR), nous avonsdeux moyens pour l’améliorer.
Le premier moyen consiste à diminuer le temps moyen de répa-ration (MTTR), autrement dit de réparer rapidement le réseau.Dans les réseaux IP/MPLS, cela est possible avec l’utilisation deprotocoles de routage dynamique qui permettent de recalculer unchemin dynamiquement afin de contourner la panne d’un lien oud’un nœud. Dans le paragraphe 2 « Diminution du MTTR :reroutage », on décrit succinctement comment minimiser ce tempsde réparation.
La disponibilité d’un système ou d’un réseau, telle quedécrite dans les documents [1] [2] ou [3], correspond à « la pro-babilité que le système fonctionne à l’instant t ». De manièresimple, la disponibilité est la proportion de temps pendantlequel le système fonctionne (correctement). C’est le ratio dutemps pendant lequel le système fonctionne sur le temps del’intervalle considéré.
Un exemple de disponibilité est 100/168 si le système peut êtreutilisé 100 h par semaine.
La disponibilité peut être calculée à partir de laconnaissance du temps moyen jusqu’à la défaillance (MTTFMean Time To Failure ) et du temps moyen de restauration(MTTR Mean Time To Repair ) = MTTF/(MTTF + MTTR).
Tableau 1 – Indisponibilité annuelle en fonctionde la disponibilité
DisponibilitéDurée cumulée
de pannes par an
0,9 Un 9 36 j
0,99 Deux 9 3,7 j
0,999 Trois 9 9 h
0,999 9 Quatre 9 53 min
0,999 99 Cinq 9 5 min
http://-/?-http://-/?-http://-/?-
-
8/19/2019 Te7585 Haute Disponibilite Dans Les Reseaux IP
3/15
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copieest strictement interdite. – © Editions T.I. TE 7 585 – 3
____________________________________________________________________________________________ HAUTE DISPONIBILITÉ DANS LES RÉSEAUX IP
Le second consiste à augmenter le temps de fonctionnementcorrect du réseau avant une panne (MTTF), autrement dit de nepas tomber en panne. Les techniques ayant pour but d’éviter que
les pannes aient un impact sur l’acheminement des paquets dansle réseau sont décrites dans le paragraphe 3. Il s’agit donc demasquer le maximum de pannes.
1.3 Taxonomie des pannes
Les causes des pannes affectant la disponibilité des réseaux IP/ MPLS sont multiples. Une étude, réalisée par le groupe deconsultant Network Strategy Partners [6], donne la répartitionsuivante en fonction de la cause des pannes (figure 1).
Comme nous allons le décrire et afin d’améliorer au mieux ladisponibilité des réseaux, il est nécessaire de traiter d’une manière
spécifique chaque type de panne.
2. Diminution du MTTR :reroutage
2.1 Architecture fonctionnelled’un routeur
L’architecture fonctionnelle des routeurs repose sur une sépara-
tion logique des fonctionnalités supportées par l’équipement, et ceen deux plans (figure 2).
Le plan de contrôle ou plan de commande (Control Plane )constitue la partie « intelligente » du routeur. Il établit et maintientdes tables de routage (RIB, Routing Information Base ) grâce auxprotocoles de routage qui permettent de déterminer la route à uti-liser vers toutes les destinations du réseau, et ce grâce à deséchanges d’informations sur l’état du réseau entre les plans decontrôle de chaque routeur. On distingue les protocoles de routageinterne IGP (Interior Gateway Protocol ), tels que OSPF, IS-IS et RIP,et les protocoles de routage externes EGP (External Gateway Protocol ), tels que BGP ou MP-BGP. Dans les réseaux MPLS, ce
plan gère également les tables de labels mises à jour à partir desprotocoles de distribution de labels tels que LDP ou RSVP-TE. Pource faire, il utilise des protocoles et des algorithmes complexesnécessitant une quantité de mémoire et une puissance de calcul« importante », de l’ordre de grandeur d’un PC de bureau. Il n’apas à effectuer de traitements « temps réels » par rapport à l’ache-minement des paquets. Son échelle de temps de réaction est celuides temps de convergence des protocoles de routage utilisés dansles réseaux, c’est-à-dire de l’ordre de quelques centaines de milli-secondes pour les protocoles de routage interne (OSPF, IS-IS) àquelques secondes à dizaines de secondes pour les protocoles deroutage externes (BGP).
Figure 1 – Causes d’indisponibilité
Mise à jourmatérielle
9 %
Logicielle25 %
Matérielle14 %
Électrique1 %
Inconnue9 %
Lien20 %
Mise à jourlogicielle
22 %
Figure 2 – Vue logique des routeurs
FIB LFIB
Aiguillage Plan detransfert
Calcul deschemins, contrôled‘admission
Protocole deroutage (OSPF,IS-IS, BGP, …)
Gestion desressources debande passante(files d‘attente)et du niveau 2
Protocole designalisation(RSVP-TE, LDP)
Plan decommande
LIB
Routage
RIB
http://-/?-http://-/?-http://-/?-http://-/?-
-
8/19/2019 Te7585 Haute Disponibilite Dans Les Reseaux IP
4/15
HAUTE DISPONIBILITÉ DANS LES RÉSEAUX IP
____________________________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copieest strictement interdite. – © Editions T.I.TE 7 585 – 4
Le plan de transfert (Data Plane ) regroupe les fonctions de commuta-tion de paquets IP/MPLS en utilisant les tables de commutation (FIB,Forwarding Information Base ) calculées par le plan de commande. Il a
pour fonction d’aiguiller les paquets IP/MPLS reçus d’une interfaced’entrée vers une interface de sortie. Cette fonction ne nécessite pas outrès peu d’intelligence mais son but est la vitesse de commutation. Parexemple, une interface OC 192 à 10 Gbit/s nécessite la commutation de4 millions de paquets par secondes. Pour cela, le plan de transfert utiliseun algorithme de commutation très simple (consultation d’une table enMPLS ou d’un arbre à typiquement 3 niveaux en IP) qui est exécuté en« hardware » par un processeur très spécifique (ASIC). Les fonctions duplan de transfert sont entre autres d’établir les adjacences de niveau 1(couche physique) et 2 (couche liaison de données) du modèle OSI avecles routeurs voisins. Le traitement comprend des fonctions deconsultation des tables de commutation (lookup ) et de qualité de ser-vice (QoS) tels que la classification, le marquage et le shaping. La bande
passante est ainsi gérée dans ce plan qui contient les files d’attentes(queuing ) plus ou moins élaborées.À ces deux fonctions principales peut s’ajouter un troisième
plan, le plan de management (Management Plane ), qui contrôleles opérations de gestion du routeur : configuration (interface enligne de commande comprise), remontées d’informations lors dedépannages (debug), connexion (telnet, console) et supervision(SNMP, journalisation).
Cette séparation logique a été standardisée à l’IETF dans legroupe de travail Forces (Forwarding and Control Element Separation ), qui modélise les nœuds IP en définissant des méca-nismes d’isolation entre les plans de contrôle et de transfert.
2.2 Temps de convergence du routageLes équipements des réseaux IP/MPLS disposent d’un plan de
commande « intelligent » leur permettant de prendre des décisionsde routage dynamiques en cas de panne. Le MTTR est donc limitéau temps nécessaire à ces équipements pour détecter la panne,puis déterminer et utiliser un autre chemin afin de contourner cettepanne (figure 3). La diminution du MTTR nécessite de rétablir rapi-dement l’acheminement correct des paquets à travers le réseau.
On peut décomposer le temps de convergence des protocolesde routage interne (IGP) de type Link State (tels que les protocolesOSPF ou IS-IS [7]) en quatre phases (figure 4) :
– détection locale de la panne physique ;
– propagation de l’information topologique (LSP pour IS-IS, LSApour OSPF) dans le réseau ;– calcul d’une route alternative et alimentation de la RIB ;– alimentation de la FIB ou des FIB.
Pour diminuer le temps de convergence et donc le MTTR, il fautminimiser chacune de ces quatre étapes.
Différentes bases d’informations d’un routeur IP
La RIB (Routing Information Base ) est la table de routage.Elle réside dans le plan de contrôle et peut être mise à jourpar plusieurs protocoles de routage.
La FIB (Forwarding Information Base ) est la tabled’aiguillage. Elle est calculée par le plan de contrôle, mais uti-lisée par le plan de transfert. La FIB est une vue simplifiée dela RIB et ne contient que les informations nécessaires àl’aiguillage des paquets.
La LIB (Label Information Base ) est la table des labels. Elleréside dans le plan de contrôle.
La LFIB (Label Forwarding Information Base ) est la tabled’aiguillage des paquets MPLS. C’est l’équivalent de la FIB
mais pour les paquets MPLS.Il y a une FIB par protocole de niveau 3 commuté par le
routeur : IPv4, IPv6, MPLS... Dans les réseaux VPN BGP/MPLS,les routeurs de type PE gèrent en plus une FIB pour chaqueVPN.
Figure 3 – Diminution du MTTR par reroutage dynamique
R1R2 R3
R5R4
Légende :
Chemin nominal
Chemin de secours
Figure 4 – Décomposition du temps de convergence (IGP)
Temps de convergencePanne
Détection Réception RIB mise à jour
PropagationCalcul des routes
Alimentation FIB
Temps
FIB mise à jour
T0 T1 T2 T3 T4
http://-/?-http://-/?-http://-/?-http://-/?-
-
8/19/2019 Te7585 Haute Disponibilite Dans Les Reseaux IP
5/15
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copieest strictement interdite. – © Editions T.I. TE 7 585 – 5
____________________________________________________________________________________________ HAUTE DISPONIBILITÉ DANS LES RÉSEAUX IP
2.3 Détection rapide
La panne peut être détectée par deux moyens :
– détection directe par remontée de l’information du plan detransfert ;
– détection indirecte par les mécanismes « Hello ».
2.3.1 Détection de la pannepar le plan de transfert
Si les routeurs utilisent des interfaces point-à-point directementraccordées par une fibre optique, la coupure de la fibre est détec-tée par la perte du signal – électrique ou optique – de la couchephysique (couche 1 du modèle OSI). C’est par exemple le cas desinterfaces POS (Packet over SONET/SDH) qui sont configuréesavec un framing SDH et une encapsulation hdlc-like . En cas depanne d’un de ces liens, la couche 2 (SDH) génère des alarmes
POS et alerte le routeur.La figure 5 présente les différents timers utilisés par un routeur
Cisco, qui ne reçoit plus de lumière (laser) sur le récepteur de sacarte POS, pour générer une alarme et indiquer à l’IOS que cetteinterface (ou port) doit être considérée comme inactive (étatDown). Nous pouvons constater que pour améliorer la réactivitéde cette détection il faut minimiser :
– le POS delay triggers , dont la valeur par défaut est de 0 ms ;– le carrier delay , dont la valeur par défaut est de 2 s.La figure 6 présente la réaction d’un routeur Cisco à la réception
d’un message LRDI (Line Remote Defect Indicator ) émis par lerouteur adjacent qui a détecté la panne par l’absence de lumière.
2.3.2 Détection de la panne par les mécanismesHello
La détection d’une panne directement par le plan de transfert estla méthode la plus rapide. Si elle n’est pas possible, par exempleparce que le réseau de transport sous-jacent ne le permet pas(comme un réseau Ethernet), on doit détecter la panne par desmécanismes de type Hello .
Les protocoles de routage, et en particulier les protocoles IGP,utilisent l’échange de messages périodiques de type Hello entrevoisins. La détection de la perte d’une adjacence a lieu lorsqueplusieurs messages Hello consécutifs sont perdus (figure 7). Letemps de détection dépend de deux paramètres configurables :l’intervalle de temps entre deux messages Hello et le nombre demessages perdus avant de considérer l’interface en panne.
Chaque protocole de routage a spécifié son propre mécanisme
de Hello , combinant parfois des fonctions d’échange d’informationentre les routeurs (lorsque l’interface fonctionne) et de détectionde panne lorsqu’elle ne fonctionne plus.
Plus récemment, l’IETF normalise un protocole spécifique à ladétection de panne : le protocole BFD Bidirectional Forwarding Detection [8]. C’est un protocole n’utilisant qu’un seul type de mes-sage, relativement court (24 octets), de taille fixe, conçu pour nenécessiter que des traitements légers pouvant être réalisés rapide-ment par tout processeur standard (General Purpose CPU) ou auniveau matériel par des processeurs très spécialisés (ASIC). Ce pro-tocole, en étant plus léger que les mécanismes de Hello des proto-coles de routage, pourrait permettre une détection plus rapide despannes avec également une implémentation au plus près de l’inter-
face c’est-à-dire sur les cartes d’interfaces des routeurs.
2.4 Convergence « rapide »
Les protocoles de routage utilisent des algorithmes de calcul dis-tribué. Suite à la détection de la panne, les étapes restant à effec-tuer pour un IGP de type link state tel qu’IS-IS sont :
1. propagation de l’information topologique (LSP pour IS-IS,LSA pour OSPF) dans le réseau ;
2. calcul d’une route alternative et alimentation de la RIB ;
3. alimentation de la FIB ou des FIB.
D’une manière générale, la durée de ces trois étapes dépendtrès fortement de la qualité de l’implémentation logicielle, del’effort porté sur l’optimisation des temps de convergence et dumatériel utilisé.
■ Pour la première étape, le temps de propagation de l’informa-tion topologique dépend également de la topologie du réseau eten particulier du nombre de routeurs devant propager l’informa-tion topologique entre le routeur ayant détecté la panne, d’unepart, et le routeur devant dévier le trafic.
Figure 5 – Timers et détection d’une panne physique sur une fibred’un routeur Cisco
Figure 6 – Timers et détection de la panne SDH d’un routeur Ciscosuite à une alarme POS
Plan de transfert
Panne du lien
(perte du signal
en réception)
Temps
POS delay triggers
Detection
Carrier delay
Temporisation
Alarme POS(perte du signal)
L‘interfaceest déclaréeen panne
Plan de commande
IOS
Annonce de l‘alarme
à l‘équipement voisin
(LRDI)
Interface
Plan de transfert
Réception de l‘alarme POS
(LRDI)
Interface
IOS
Plan de commande
Temps
Carrier delay
Temporisation
Prise en comptede l‘alarme POS
L‘interface est déclaréeen panne
Dans l’exemple de la figure 3, suite à la panne du lien entre R2 etR3, le routeur R2 détecte la panne du lien et l’annonce au routeur R1,qui est le routeur devant dévier le trafic. Ces deux routeurs sontsitués à un seul saut l’un de l’autre.
Figure 7 – Détection de panne par des mécanismes de type Hello
Hello Hello Hello Hello-1 Hello-2 Hello-3
PanneDétection de la panne
après la perte
de 3 messages hello
consécutifs
Temps
Temps de détection
http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-
-
8/19/2019 Te7585 Haute Disponibilite Dans Les Reseaux IP
6/15
HAUTE DISPONIBILITÉ DANS LES RÉSEAUX IP
____________________________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copieest strictement interdite. – © Editions T.I.TE 7 585 – 6
On pourrait intuitivement penser que dans des grands réseaux,cette distance topologique pourrait être grande, mais certainesétudes ont montré le contraire. Par exemple, une étude [11] a
calculé tous les cas de pannes de liens dans un réseau de taillemondiale et a montré que près de 90 % du trafic était rerouté parun routeur situé à moins de deux sauts de la panne (figure 8).
■ Pour la seconde étape, le temps de calcul de la route alternativeet la modification de la RIB dépend de la taille du réseau en nombrede nœuds et de liens et du nombre de préfixes IP à modifier dansla RIB. Le temps de calcul des plus courts chemins SPF (Shortest Path First ) est de l’ordre de quelques dizaines de millisecondes (parexemple 35 ms pour 600 nœuds).
■ Enfin pour la troisième étape, le temps de mise à jour des tablesde commutations (FIB) dépend du nombre de préfixes à modifierou réécrire. Ce temps est de l’ordre de 200 µs par préfixe, mais
compte tenu du nombre important de préfixes dans les réseauxInternet, c’est cette étape qui est la plus longue. Elle peut durer de200 ms à 10 s.
Au début des années 2000, les temps de convergence après unepanne de lien ou du routeur interne à un réseau (AS) étaient del’ordre de 10 s. En 2006, les meilleures pratiques permettentd’atteindre un temps de convergence de l’ordre de 500 ms [12].
2.5 Protection locale
En concurrence avec les mécanismes de restauration qui sontétablis après la panne, telle que la convergence des protocoles deroutage, il existe aussi des mécanismes de protection utilisant deschemins calculés et disponibles dans les tables de commutationavant que la panne n’arrive. Ces mécanismes de protection sontplus rapides, car ils minimisent les temps nécessaires à chaqueétape :
1. Détection locale de la panne physique ;2. Propagation de l’information topologique dans le réseau ;3. Calcul d’une route alternative et alimentation de la RIB ;4. Alimentation de la FIB ou des FIB.L’étape 1 de détection de la panne est inchangée.
L’étape 2 de propagation dans le réseau de l’information« panne » n’est plus nécessaire car la protection est un mécanismeactivé localement par le routeur ayant détecté la panne.
L’étape 3 de calcul des nouvelles meilleures routes est réaliséeavant la panne. Cette étape consiste pour le routeur à calculer lesmeilleures routes pour toutes les destinations et pour tous les cas
de panne qu’il peut détecter. Elle peut être relativement longue,c’est-à-dire de l’ordre de la seconde, mais cette durée n’est pasgênante car pendant ce temps, le trafic est correctement acheminé(à la différence d’un calcul réalisé consécutivement à la panne).
L’étape 4 est en grande partie effectuée avant la panne. Lestables de commutations (FIB) à utiliser après une panne sont déjàconfigurées dans les cartes d’interface. Suite à une panne, il nereste qu’à indiquer quelle table les cartes de commutation doiventutiliser.
Globalement, ces mécanismes de protection locale permettentde rétablir le trafic en 50 à 100 ms après la panne.
Dans les réseaux MPLS, le MPLS Fast Reroute [10] est une techni-que de protection locale du trafic. Elle nécessite d’utiliser un mode« connecté » en établissant des tunnels MPLS TE entre tous les rou-teurs du réseau. Le « MPLS Fast ReRoute » est normalisé à l’IETF etimplémenté depuis le milieu des années 2000. Il est déployé dansplusieurs réseaux, mais une majorité des réseaux ne l’implémentepas du fait de la complexité induite, de la nécessité d’utiliser MPLSet de l’obligation d’être en mode connecté. En effet, le modeconnecté nécessite, pour la protection des pannes de routeurs, unmaillage complet des routeurs entre eux par des LSP MPLS. SoitN (N -1) tunnels à configurer pour N routeurs dans le réseau.
Pour les réseaux IP, plusieurs propositions de Fast ReRoute IP sont en cours d’étude à l’IETF [13] [14] et dans la communauté dela recherche [15], mais aucune approche ne fait pour l’instantl’unanimité en raison des problématiques du taux de couverturedes pannes et des typologies de réseau et de la complexité des dif-férentes solutions. Ces solutions d’IP Fast ReRoute doivent permet-tre de protéger le trafic en 100 ms en cas de panne. Suite à cetteprotection locale, il est nécessaire d’utiliser les protocoles de rou-tage pour rerouter le trafic. D’une part, pour déterminer et utiliserle nouveau meilleur chemin pour traverser le réseau, et d’autrepart pour se préparer à la prochaine panne (IP Fast ReRoute nepeut protéger qu’une panne à la fois).
Lors de cette étape de reroutage, il est utile d’utiliser une tech-nique ne générant pas de boucles de routage transitoires [16] [17][18] lors de la convergence. En effet, pendant la convergence versle nouvel état stable, chaque routeur du réseau modifie ses tablesde routage indépendamment des autres routeurs et peut pro-voquer ainsi des incohérences temporaires.
3. Augmentation du MTTF– Haute disponibilité
Dans la partie précédente (§ 2), on a détaillé les différents méca-nismes de convergence relatifs aux protocoles de routage au seind’un réseau. Pour diminuer les pertes de paquets dues aureroutage, les techniques de haute disponibilité implémentées surles routeurs IP essaient quant-à-elles de masquer certaines pannesaux autres routeurs du réseau. Le principe sous-jacent est d’utiliserdes architectures redondées pour pallier différents cas de pannes.
Figure 8 – Distance entre le lien en panne et le routeur reroutantle trafic
0 2 4 6 8 10 12
0,1
0,2
0,3
0,4
0,5
0,6
T r a f i c
r e r o u t é ( % )
N : nombre de sauts (nombre de routeurs) entre le routeur détectantla panne et le routeur devant changer sa RIB pour rétablir le trafic.
N
Les tunnels MPLS sont unidirectionnels. Il faut donc établirdeux fois plus de tunnels que pour un simple maillagecomplet (N (N -1)/2).
Dans l’exemple de la figure 3, si au temps t 1 le routeur R2 redirigevers R1 le trafic à destination de R3, alors qu’au temps t 2 > t 1 , lerouteur R1 redirige vers R4 le trafic à destination de R3, alors pendantl’intervalle de temps [t 1 , t 2 ], une boucle de routage est formée entreR2 qui redirige le trafic vers R1 et R1 qui continue encore a redirigerle trafic vers R2.
http://-/?-http://-/?-http://-/?-http://-/?-
-
8/19/2019 Te7585 Haute Disponibilite Dans Les Reseaux IP
7/15
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copieest strictement interdite. – © Editions T.I. TE 7 585 – 7
____________________________________________________________________________________________ HAUTE DISPONIBILITÉ DANS LES RÉSEAUX IP
3.1 Contraintes de haute disponibilitéau niveau du plan de transfert
et Non Stop Forwarding Puisque c’est au niveau du plan de transfert que le paquet est
aiguillé, il faut, pour augmenter la disponibilité d’un routeur, avoirune table de commutation (forwarding ) à jour de manière à ce queles paquets soient toujours transférés vers la bonne destination.Pour ce faire, il faut à la fois maintenir la stabilité et la cohérencedes protocoles de routage, mais aussi accélérer la distribution desinformations de commutation (forwarding ) vers le plan de trans-fert. Cette distribution de la RIB vers la FIB est purement interne aurouteur et très dépendante des choix des constructeurs. Les para-mètres sur lesquels il est possible de jouer sont :
– la quantité d’information à télécharger dans la FIB ;– la vitesse de calcul des processeurs du plan de transfert ;
– la bande passante disponible entre les cartes de transfert et decontrôle ;
– les processus de synchronisation entre les différentes cartes.
Pour répondre aux demandes de performances et assurer unemeilleure évolutivité au cours du temps, les architectures maté-rielles sont de plus en plus distribuées. La séparation fonctionnelledécrite précédemment (§ 2.1) se retrouve dans l’architecture maté-rielle des routeurs de cœur où les plans sont répartis sur des cartesmatérielles distinctes. Certaines supportent le plan de transfert,d’autres sont dédiées au plan de commande et supportent parfoiségalement le plan de management. Ces dernières peuvent êtreaussi redondées pour une meilleure disponibilité. En effet, les fonc-tions de haute disponibilité reposent sur deux constats :
– d’une part, dans les routeurs à très haut débit des opérateursde réseaux IP/MPLS, les fonctions de plan de commande et de plande transfert sont bien séparées. Elles sont effectuées par des proces-sus logiciels différents s’exécutant sur des cartes matérielles distinc-tes. Ainsi et dans une très large proportion, les pannes affectant leplan de commande sont indépendantes des pannes affectant le plande transfert ;
– d’autre part, les opérations effectuées par le plan de transfertsont essentiellement effectuées par des composants matériels (desprocesseurs spécialisés de type ASIC) alors que les opérationseffectuées par le plan de commande sont essentiellement réaliséespar des composants logiciels. Les composants logiciels complexesayant un taux de pannes plus élevé, le plan de transfert est plus
robuste que le plan de commande.Compte tenu des deux caractéristiques, le principe des fonctionsde haute disponibilité est de permettre au plan de commande des’arrêter (suite à un bug par exemple), puis de redémarrer sansimpacter le plan de transfert qui continue de son côté à commuterles paquets.
Pour y parvenir, le plan de transfert du routeur doit donc d’unepart maintenir ses adjacences de niveau 2, de façon à masquer lapanne à ses routeurs voisins. D’autre part, le routeur doit êtrecapable de poursuivre le transfert de paquets sans interruption enmaintenant les tables de commutation (comme les FIB et LFIB).C’est ce que l’on appelle la capacité NSF ou Non Stop Forwarding .En revanche, lors d’une panne liée au plan de transfert, comme la
perte d’une carte d’interface, la perte de paquets est inévitablejusqu’à ce que le trafic soit rerouté.
3.2 Contraintes de haute disponibilitéau niveau du plan de commande
Les pannes relatives au plan de contrôle résultent soit d’unepanne logicielle, soit d’une panne matérielle sur carte decommande. D’autres indisponibilités du plan de contrôle sont duesaux mises à jour logicielles des équipements. Redémarrer une cartede commande sur un routeur de cœur nécessite en généralplusieurs minutes, de l’ordre d’une dizaine. Or une indisponibilitétotale de la machine pendant dix minutes n’est pas réaliste si l’on
veut atteindre les « cinq neuf ». C’est pourquoi des efforts sur lamodularité des systèmes ont été réalisés, de manière à redémarrerle plus vite possible un processus ou une carte de commande toute
entière, pour repartir sur un processus dans un état sain ou unecarte saine.
Lors d’une panne du plan de contrôle, les protocoles de routageset en particulier les sessions établies avec les routeurs voisins sontinterrompus. Lorsqu’une véritable séparation des plans decommande et de transfert est réalisée, deux solutions concurrentessont possibles pour améliorer la disponibilité lors de la perte duplan de commande. Elles sont respectivement décrites dans lesparagraphes 3.4 et 3.3. La première solution (GR) consiste à utiliserdes adaptations des protocoles de routage pour que les deux rou-teurs voisins se coordonnent pour gérer localement cette pannelors du redémarrage du plan de commande, sans en informer lereste du réseau. La seconde (NSR) ne nécessite pas un changement
des protocoles de routage et repose sur la redondance et la syn-chronisation interne au routeur des deux cartes du plan decommande. Elle ne nécessite pas non plus la collaboration deséquipements voisins.
Utilisées en complément du Non-Stop Forwarding , ces deuxsolutions assurent une continuité de service lors d’une panne et duredémarrage de la carte de plan de contrôle.
3.3 Capacité NSR ou Non Stop Routing
Le Non Stop Routing est une capacité spécifique d’un routeur qui
lui permet, lors d’une panne relative au plan de contrôle, de bascu-ler sur une seconde carte de commande de secours sans perte depaquets et sans incidence sur les voisins. Les adjacences de routagene sont pas perturbées et restent maintenues durant la panne. LeNon Stop Routing repose sur la redondance des cartes decommande, qu’elle soit totale ou partielle. Cette redondance peutêtre matérielle ou logicielle. Dans les deux cas, outre la synchroni-sation des tables de routage ou des configurations, la fiabilisationdes processus de routage nécessitent la synchronisation de nom-breux points de reprises et d’états entre le système primaire et lesecondaire.
Cette solution est délicate à implémenter pour les constructeurs,qui peuvent parfois proposer le Non Stop Routing uniquement surun sous-ensemble des protocoles de routage. Ils peuvent proposersoit un parallélisme complet entre les deux cartes de commande,soit une synchronisation partielle de certains états pour certainsprotocoles (par exemple la table de routage, l’état de la machine àétats, quelques timers ) ou encore déclencher une synchronisationcomplète sur certains événements.
En revanche, pour un opérateur, le Non stop routing présente denombreux avantages car il est totalement transparent vis-à-vis desrouteurs voisins et est donc plus facile à déployer.
3.4 Extensions GR ou Graceful Restart
Si l’équipement n’est pas capable de maintenir seul ses tables etadjacences de routage, il existe des extensions protocolaires quilui permettent en cas de perte du plan de contrôle primaire deréacquérir, avec l’aide des routeurs voisins, les informations
Dans le dossier [H 5 850] réf. [34], la tolérance aux fautes
des applications de routage est détaillée.
Pour plus d’informations sur les points de reprise et lasûreté de fonctionnement, on peut se reporter à [H 2 508] réf.
[3], [H 2 509], réf. [4].
-
8/19/2019 Te7585 Haute Disponibilite Dans Les Reseaux IP
8/15
HAUTE DISPONIBILITÉ DANS LES RÉSEAUX IP
____________________________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copieest strictement interdite. – © Editions T.I.TE 7 585 – 8
nécessaires pour reconstruire ses bases d’information. Les autresrouteurs du réseau ne sont pas informés de cette panne.
Ces extensions de routage sont appelées Graceful Restart (GR) ;elles reposent sur la coopération entre un routeur IP qui subit unepanne de plan de contrôle et l’ensemble de ses voisins. C’estl’approche la plus courante pour réduire les pertes de services.
Cela est disponible dans la plupart des équipements récents quiont une bonne séparation entre les plans de contrôle et de transfert,et ceux qui supportent la redondance des plans de contrôle. Lesextensions GR sont également disponibles sur les routeurs qui n’ontqu’un seul plan de contrôle. Combinées aux capacités de maintiendes adjacences de niveau 2 et au maintien de la commutation depaquets, ces extensions permettent de minimiser fortement l’inci-dence d’un redémarrage ou d’un basculement de carte de contrôleprimaire sur le trafic : le GR est typiquement combiné au NSF.
Pour un équipementier, cette solution protocolaire est plussimple à implémenter que la solution NSR purement interne à unéquipement et qui demande des fonctions de redondance et desynchronisation plus avancées. En effet, le GR nécessite moinsde synchronisation d’états entre les contrôleurs primaires etsecondaires puisqu’il est possible de redemander aux routeursvoisins les informations de routage perdues.
3.4.1 Protocoles IGP
Le routage IGP (Interior Gateway Protocol ) est primordial sur unréseau dans la mesure où il assure le routage au sein d’undomaine. Deux protocoles dits à états de lien sont principalementutilisés en tant qu’IGP sur un réseau de cœur IP : OSPF [21] et IS-IS(défini dans [22] et décrit dans [7]).
Les extensions Graceful Restart ont pour but d’aider un routeurdont le plan de contrôle redémarre à maintenir ses adjacences IGPet poursuivre le transfert de paquets sur les routes apprises parl’IGP malgré la perte des sessions de routage avec ses voisins. Sansles extensions Graceful Restart , l’IGP doit converger dès qu’uneadjacence est modifiée, c’est-à-dire dès qu’il y a perte de la session,que ce soit à cause d’une panne de lien ou de plan de contrôle. Laconvergence implique le calcul du plus court chemin selon l’algo-rithme SPF (Shortest Path First ), comme vu au paragraphe 2.
Avec les extensions Graceful Restart , les pertes des sessions deroutage avec les routeurs voisins sont masquées aux reste duréseau, ce qui réduit le trafic de commande (annonces protocolai-res de type LSP pour IS-IS ou LSA pour OSPF), élimine des calculsde plus courts chemins et les boucles de routage temporaires lorsde la convergence.
3.4.1.1 GR pour le protocole IS-IS
Les extensions Graceful Restart pour le protocole IS-IS [26] sontannoncées dans les messages Hello sous la forme d’un nouveau
TLV (Type Length Value Élément Type Longueur Valeur, structured’encodage utilisée dans de nombreux messages protocolaires).Le TLV 211 (figures 10 et 11) contient deux informations :
– deux bits significatifs sur le premier octet sont utilisés pour lesannonces RR (Restart Request ) ou RA (Restart Acknowledgement ) ;
– le temps restant dans la procédure Graceful Restart est codé sur2 octets ; ce timer est utilisé par les routeurs en cours de redémar-rage (restarting , et non les receiving ) et indique le temps maximalqui leur est alloué pour redémarrer et terminer la procédure de GR.
Deux autres timers sont définis dans [26] :
– une instance du timer T1 est maintenue par interface, indiquantle temps après lequel une tentative de redémarrage non acquittée
est relancée ; il est de trois secondes par défaut ;– une instance du timer T2 est maintenue pour chaque base LSP
(une par niveau, level 1 et level 2), indiquant le temps maximalpendant lequel un système va attendre la synchronisation desbases LSP (LSDB ou LS DataBase ) ; il est de soixante secondes pardéfaut.
Exemple : dans le réseau illustré par la figure 9, seuls les routeursR1 et R3 sont informés de la panne du plan de commande du routeurR2 et ont besoin d’y réagir en ré-établissant leur protocoles de rou-tage avec le routeur R2.
Terminologie
Chaque constructeur utilise sa propre terminologie pourdécrire les caractéristiques de Graceful Restart et de Non Stop Forwarding . Les extensions GR étant normalisées au sein del’IETF, nous utilisons le vocabulaire suivant :
– un routeur effectuant un basculement de plan de contrôleet capable de comprendre les extensions GR est appelé res- tarting routeur, ou encore « capable » ;
– les voisins d’un routeur dont le plan de contrôle redé-marre et qui comprennent les extensions GR sont qualifiéesde helper ou aware . Dans les normes, on les appelle égale-ment les routeurs receiving .
Figure 9 – Augmentation du MTTF par utilisation de fonctionsde haute disponibilité dans le plan de commande
Figure 10 – Extensions GR pour IS-IS : description du TLV 211
Figure 11 – TLV 211 : description des flags
Chemin de commutation
Protocole de routage
Plan de commande
Plan de transfert
Légende :
R1R2
R3
R5R4
0 1 2 3 4 5 6 7
Flags
Temps restant
Identification du voisin “restarting ”
0 1 2 3 4 5 6 7
RRRASA
RR : requête de redémarrage (Restart Request)
RA : acquittement du redémarrage (Restart Acknowledge)
SA : supprime l'annonce de l'adjacence
(Suppress Adj Advertisement)
http://-/?-http://-/?-
-
8/19/2019 Te7585 Haute Disponibilite Dans Les Reseaux IP
9/15
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copieest strictement interdite. – © Editions T.I. TE 7 585 – 9
____________________________________________________________________________________________ HAUTE DISPONIBILITÉ DANS LES RÉSEAUX IP
3.4.1.2 GR pour le protocole OSPF
Les extensions Graceful Restart pour le protocole OSPF sontdéfinies dans [22]. La procédure classique est proche de celledécrite précédemment pour IS-IS. Dans le cas d’OSPF, les routeursne savent pas a priori si leurs voisins supportent ou non le GR.Après une panne (switchover ), le routeur restarting marque sesentrées de commutation (forwarding ) comme gelées (stale ) etenvoie des messages appelés Grace-LSAs sur chacune de sesinterfaces, avec l’option « cause du redémarrage » positionnée à« inconnue » ou « a basculé sur la carte secondaire ». Si le voisin
supporte le mode GR, alors il devient helper et aide le routeurredémarrant à reconstruire sa base LSDB.
3.4.2 Protocole (MP-)BGP
BGP Graceful Restart est une extension du protocole (MP-)BGPdéfini par l’IETF dans la RFC 4724 [19]. Il permet à une sessionBGP d’être interrompue puis de redémarrer sans que cela ne modi-fie le routage BGP sur les deux routeurs utilisant cette session nidans le reste du réseau.
Sans cette extension, lorsqu’un routeur A détecte une panne de lasession BGP vers le routeur B, le routeur A considère que le routeur B
n’est plus fonctionnel et qu’il ne doit plus lui envoyer du trafic. Ainsi,il considère que toutes les routes BGP reçues du routeur A par cettesession sont invalides et déclenche un calcul de meilleure route BGPpour déterminer les routes de secours à utiliser.
Le principe des fonctions de haute disponibilité et de Graceful Restart est de considérer qu’une panne de la session BGP ne signi-fie pas obligatoirement que le routeur n’est plus capable d’ache-miner correctement les paquets, mais que le problème peut êtrelimité au fonctionnement de BGP, par exemple dans le cas d’unbug du processus BGP.
Comme pour les extensions GR des autres protocoles de rou-tage, le routeur redémarrant son processus BGP est appelé lerouteur restarting et le routeur n’ayant pas subi d’incidents mais
coopérant avec le restarting est appelé receiving . Sachant qu’unrouteur dispose de plusieurs sessions BGP, il y a alors plusieursrouteurs receiving impliqués.
La première étape du BGP Graceful Restart commence avant lapanne lors du premier établissement de la session BGP. Les deuxrouteurs négocient ce nouveau comportement en s’échangeantune capacité Graceful Restart selon la procédure décrite dans laRFC 3392 [20].
Cette capacité spécifie (figure 14) :– le support de BGP GR en mode helper ;– l’éventuelle capacité du routeur à continuer d’acheminer cor-
rectement les paquets pendant l’interruption du plan de commandeet le redémarrage de la session BGP pour les familles d’adresses
Le schéma de la figure 12 décrit la procédure GR pour un routeurrestarting IS-IS GR (appelé R1) et son voisin receiving (R2).
1. Le routeur R1 redémarre.2. R1 envoie un message de type Hello (IIH) contenant le TLV 211
avec le bit RR positionné et le bit RA à 0, indiquant que R1 a redé-marré.
3. R2 reçoit le message Hello de R1.4. R2 étant un voisin helper ou receiving , il répond par un message
de type Hello contenant le TLV 211 avec le bit RR à 0 et le bit RApositionné ; R2 acquitte ainsi le Hello reçu de R1 et sa demande deGR.
5. R1 reçoit le Hello de R2.6. Si l’interface est de type point-à-point, ou si R2 a une priorité
plus forte parmi tous les routeurs dont les paquets Hello (IIH)contiennent le TLV restart à l’exception de R1, R2 envoie un jeu
complet de paquets CSNP (Complete Sequence Number PDU , listantle contenu locale de la LSDB). Lorsque le CSNP et le message Hello précédent sont reçus, le timer d’adjacence est annulé. Si le délai demaintien d’adjacence expire, R1 renvoie le message Hello avec le bitRR positionné.
Lorsque l’un des voisins ne supporte par les extensions Grace- ful Restart (figure 13) :
1. Le routeur R1 redémarre.2. R1 envoie un message de type Hello (IIH) contenant le TLV 211
avec le bit RR positionné et le bit RA à 0, indiquant que R1 a redé-marré.
3. R2 reçoit le message Hello de R1.
4. R2 étant un voisin non-helper , il répond par un message de typeHello ne contenant pas de TLV 211 ; l’adjacence est supprimée.5. R1 reçoit le Hello de R2 sans TLV 211, il réinitialise l’adjacence
avec R2. R1 envoie un message de type Hello avec le TLV 211 maisavec les bits RR et RA à 0, pour lancer une procédure d’établisse-ment d’adjacence classique (6).
Figure 12 – Procédure IS-IS Graceful Restart entre un routeur
restarting et un voisin receiving
Routeur R1Restarting
Routeur R2Receiving
Démarrage du
timer Hello
IS-IS Hello (IIH)
IS-IS Hello (IIH)RR=1, RA=0
RR=0, RA=1
LSP
CSNP
1 2
34
6
5
Figure 13 – Procédure IS-IS Graceful Restart entre un routeurredémarrant GR-restarting et un voisin non-receiving
Notons qu’un autre mécanisme existe pour permettre à unrouteur d’informer ses voisins que son processus OSPFredémarre : Restart Signaling [23]. Il s’agit d’un mécanismepropriétaire d’un équipementier qui a été implémenté avantles extensions GR.
Routeur R1Restarting
Routeur R2Non-GR
Démarrage dutimer Hello
IS-IS Hello (IIH)
IS-IS Hello (IIH)
IS-IS Hello (IIH)
RR=1, RA=0
Pas de TLV 211
1 2
34
6
5
TLV211, RR=0, RA=0
http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-
-
8/19/2019 Te7585 Haute Disponibilite Dans Les Reseaux IP
10/15
HAUTE DISPONIBILITÉ DANS LES RÉSEAUX IP
____________________________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copieest strictement interdite. – © Editions T.I.TE 7 585 – 10
spécifiées dans les champs Address Family Identifier et Subsequent Address Family Identifier (par exemple, IPv4, IPv6, VPN...) ;
– la durée maximale, appelée Restart Time , que le routeur hel- ping accorde au routeur restarting pour rétablir la session BGP.
La procédure de Graceful Restart échoue et est interrompue si lerouteur restarting ne réétablit pas ses sessions BGP à temps (c’est-à-dire avant l’expiration du délai Restart Timer ) ou s’il indiquequ’il n’a pu continuer à acheminer les paquets. Dans ce cas, le rou-teur receiving supprime les routes marquées stale et considère lasession BGP comme close.
3.4.3 Protocoles de distribution de labels
Deux protocoles permettent de distribuer les labels dans lesréseaux MPLS [29] :
– le protocole LDP (Label Distribution Protocol , défini dans [27]et décrit dans [29] ;
– le protocole RSVP-TE (ReSerVation Protocol-Traffic Enginee-ring, défini dans [31] et décrit dans [10]).
Ces protocoles sont utilisés lorsque les paquets sont labellisés,que ce soit dans un contexte de trafic Internet avec une commuta-
tion MPLS ou dans des environnements de type VPN MPLS où lesréseaux privés virtuels sont construits grâce au MPLS.
3.4.3.1 GR pour le protocole LDP
Plusieurs modes de distribution de labels par LDP sont normali-sés. Les extensions GR pour le protocole LDP, appelées aussi Fault Tolerant (FT) sont définies dans [30] [35] pour la méthode down- stream unsolicited (la plus répandue).
Comme pour l’IGP et le (MP-)BGP, les extensions GR pour LDPnécessitent des modifications à la fois sur le routeur qui redémarreet sur ses voisins qui supportent le mode helper . L’extensioncomprend un nouveau TLV optionnel spécifique, appelé TLV desession tolérante aux fautes (FT). Ce TLV est échangé au moment
de l’établissement de la session LDP, dans les messages Hello , et aété conçu de manière à être compatible avec les messages Hello de LSR ne supportant pas les extensions GR.
Comme indiqué sur la figure 16, le TLV spécifie deux timers :– Reconnect Timeout est la durée en millisecondes pendant
laquelle le routeur expéditeur du TLV souhaite que le routeurreceiving attende après la détection de la panne LDP. Pendantcette période de temps, le destinataire maintient les états MPLSdans sa table de commutation (forwarding ) pour les LSP préétablisqui traversent un lien entre l’expéditeur et lui-même. Ce timer doitêtre suffisamment grand pour permettre le redémarrage du plande contrôle de l’expéditeur et surtout le redémarrage des échangesLDP avec ses voisins, soit 120 s par défaut. Si ce timer a pour
Figure 14 – Capacité Graceful Restart de BGP
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Capability Code (64) Capability Length
Restart Flags
Address Family Identifier (16 bits)
Subsequent Address Family Identifier
Subsequent Address Family Identifier
Flags for Address Family
Flags for Address Family
…
… …
Address Family Identifier (16 bits)
Restart Time (in seconds)
Après cette première étape (étape 1) d’échange de la capacitéGraceful restart , la session BGP se déroule normalement (étape 2) etchaque routeur peut s’échanger des messages de routage Updates(figure 15).
En cas de panne du routeur restarting (étape 3), le routeur receiving conserve et continue à utiliser les routes apprises par cette sessionBGP (étape 4). Il marque néanmoins ces routes comme stale afin depouvoir les supprimer à la fin de la procédure de Graceful Restart .Lors du rétablissement de la session BGP (étape 5), le routeur restar- ting doit annoncer son état dans le message BGP Open et plus préci-sément dans la capacité Graceful Restart . Il indique dans le champRestart Flag qu’il a redémarré et dans le champ Flags for Address Family s’il a été capable de continuer à commuter les paquets IP/ MPLS comme prévu.
Suite à cette ouverture de session BGP, le routeur receiving annoncetoutes ses routes BGP (étape 6) puis envoie un message indiquant
qu’il a fini de transmettre la table de routage. Ce message appelé End of RIB est constitué d’un message BGP de taille minimale s’il s’agitd’une session BGP standard, ou constitué d’un message MP-BGP necontenant que l’attribut MP_UNREACH_NLRI sans aucune route s’ils’agit d’une session BGP multiprotocole.
À la réception de ce marqueur de fin de RIB (étape 7) sur toutesses sessions BGP, le routeur restarting sait qu’il a reçu l’intégralitédes routes BGP. Il peut donc reprendre le comportement normal deBGP et en particulier calculer les nouvelles meilleures routes, mettreà jour sa table de commutation (FIB) avec des informations à jour, etannoncer ses meilleures routes aux routeurs BGP avec lesquels il aune session. Cela permet aux routeurs receiving de mettre à jourleurs routes. Suite à l’envoi de l’ensemble de sa table de routage, il
envoie également le marqueur de fin de RIB. À sa réception, lesrouteurs receiving suppriment l’ensemble des routes stalled restantes(c’est-à-dire, celles qui n’ont pas été réannoncées après le redémar-rage) puis recalculent leurs meilleurs routes. Cela clôt la procédure deGraceful Restart et dorénavant la session BGP continue de manièreconventionnelle.
En résumé, les routeurs receiving accordent un peu de tempsau routeur restarting pour redémarrer ses sessions BGP et confir-mer qu’il a continué à acheminer les paquets IP/MPLS commeprévu. Puis les routeurs receiving réannoncent l’ensemble deleurs routes BGP afin que le routeur restarting puisse les réap-prendre. Pendant ce temps, le routeur restarting achemine toujoursles paquets en utilisant l’ancienne table de commutation (FIB)que son plan de transfert a conservé. Après réception de toutesles routes de toutes les sessions, le routeur restarting recalcule
ses meilleures routes BGP, met à jour sa table de commutationet annonce ses meilleures routes aux routeurs receiving .
-
8/19/2019 Te7585 Haute Disponibilite Dans Les Reseaux IP
11/15
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copieest strictement interdite. – © Editions T.I. TE 7 585 – 11
____________________________________________________________________________________________ HAUTE DISPONIBILITÉ DANS LES RÉSEAUX IP
valeur 0, l’émetteur des TLV ne préservera pas ses états decommutation (forwarding ), même s’il supporte les procédures ;
– Recovery Time est la durée en millisecondes pendant laquellele LSR qui redémarre souhaite préserver sa LFIB. Ce timer démarreau moment où l’émetteur envoie son message d’initialisationcontenant le TLV LDP FT. Si ce timer est à 0, cela indique que laLFIB n’est pas maintenue pendant le redémarrage.
Figure 15 – BGP Graceful Restart
Figure 16 – Description du TLV pour les sessions LDP FT
Restarting
RouteurRouteur
Receiving
Open - GR (IPv4)
Open - GR (IPv4)
Updates ; keepalives
Open - GR (restart , commutation IPv4 OK)
Open - GR (IPv4)
Updates
Updates
End Of RIB
End of RIB
Plan de contrôle non OK:- Il est ré-initialisé
Plan de transfert OK:- FIB OK- commutation OK
Calcul de routes BGP
Envoi de la table de routage
Redémarrage de la sessionmais conservation des routes
Envoi de la table de routage
Calcul de routes BGP
11
22
3
5
7
4
6
7
0
01
0
1 2 3 4 5 6 7 0
1
1 2 3 4 5 6 7 0
2
1 2 3 4 5 6 7 0
3
1 2 3 4 5 6 7
TLV session FT (0x0503) Longueur (=12)
Flags FT Réservé
FT Reconnect Timeout (en millisecondes)
Recovery Time (en millisecondes)
Les étapes de la procédure GR (figure 17) sont les suivantes :
1. Le routeur LSR R1 indique qu’il supporte les extensions GR pourLDP en mode capable en envoyant un message d’initialisation detype Hello contenant le TLV Fault Tolerant . Dans ce paquet, le champL (Learn from Network ), comme indiqué sur la figure 18 est posi-tionné à 1 pour indiquer que les procédures GR LDP sont en cours.
2. Réciproquement, le routeur LSR R2 envoie ce même messaged’initialisation.
3. Les LSR échangent des informations de labels.
4. Lorsqu’un basculement de plan de contrôle se produit, le pro-cessus LDP du routeur qui redémarre établit une nouvelle sessionTCP avec ses voisins. Le routeur GR-capable démarre un timer
interne, délai pendant lequel il marque ses entrées MPLS dans laLFIB comme gelées ou stale . Le routeur est alors en mode de redé-marrage (restart mode ), le temps que la procédure GR finisse.
5. Après détection de la panne, le voisin supportant LDP-GR initia-lise un timer qui indique la durée pendant laquelle ce voisin LSRconserve ses associations FEC-labels pour les labels stale . Si leLSR qui redémarre n’a pas ré-établit de session LDP avant la fin de cetimer , alors les associations stale sont supprimées.
6. Le LSR qui redémarre envoie un message d’initialisation, danslequel le timer Recovery Time indique le temps pendant lequel laLFIB sera maintenue.
7. La session LDP est désormais établie. Si la session LDP est ré-établie avant que le timer Reconnect expire, ce timer est arrêté et letimer Recovery démarre.
Une fois la session établie, les routeurs échangent à nouveau leursmessages contenant les préfixes et les labels associés. Les routeursLDP utilisent un autre timer , lancé lorsque le message d’initialisationest envoyé. Lorsqu’il expire, LDP supprime toutes les associationsmarquées comme stale dans la base de labels (LIB), ce qui déclenchela suppression de tous les états de commutation (forwarding ) asso-ciés dans la LFIB.
http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-
-
8/19/2019 Te7585 Haute Disponibilite Dans Les Reseaux IP
12/15
HAUTE DISPONIBILITÉ DANS LES RÉSEAUX IP
____________________________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copieest strictement interdite. – © Editions T.I.TE 7 585 – 12
3.4.3.2 GR pour le protocole RSVP-TE
Les extensions Graceful Restart pour le RSVP-TE sont docu-mentées dans [32][36][37].
Deux timers sont utilisés durant la procédure RSVP GR :
– Restart timer est le temps total nécessaire au routeur pourredémarrer RSVP-TE et ré-envoyer les messages de type Hello avec ses voisins ;
– Recovery Time est la période durant laquelle les routeurshelper et le routeur qui subit la panne resynchronisent leurs états
(informations RSVP-TE et LFIB) après la reprise des échangesHello . Lorsque le LSR qui redémarre est incapable de maintenir saLFIB, il envoie un recoveryTime de 0.
3.5 Protocoles multicast
3.5.1 NSF pour le multicast
À l’image des protocoles unicast, et pour éviter la perte de traficlors d’une panne de plan de contrôle, le routeur IP doit savoirmaintenir sa FIB multicast lors du basculement vers la carte secon-daire. De cette façon, les adjacences multicast de niveau 3 sontmaintenues et le routeur continue à commuter les paquets, en uti-lisant l’ancienne FIB. Après la convergence des protocoles multi-cast, les informations apprises par la nouvelle carte de commandesont recoupées avec les informations existantes. Les entréesgelées sont purgées, ce qui permet une transition en mode NSF.
3.5.2 Exemple avec le protocole PIM
Le protocole PIM-SM (Protocol Independent Multicast – Sparse Mode [33]) ne possède pas d’extensions spécifiques de type GRcar il intègre de façon native des fonctions de récupération d’états.Ainsi, le routeur PIM-SM utilise un mécanisme appelé Generation identifier pour indiquer les redémarrages. Ces identifiants sontinclus par défaut dans les messages Hello et un identifiant initialest créé par chaque voisin PIM afin d’échanger les capacités du
routeur. Lorsqu’un des voisins PIM redémarre, il envoie un nouvelidentifiant à ses voisins. Ceux qui supportent le GR l’aident àrafraîchir ses états en envoyant des mises à jour multicast aunœud qui redémarre.
4. Opérationsde maintenancedans les réseaux IP
Des opérations de maintenance sont régulièrement réalisées parles opérateurs de réseaux sur les équipements de transmission etde commutation. Ces opérations ont principalement pour but demettre à jour la version logicielle d’un routeur afin de corriger desfailles de sécurité ou de disposer de nouvelles fonctionnalités, et/ ou d’augmenter la capacité d’un lien/routeur afin de faire face àl’augmentation du trafic.
Par rapport aux pannes, ces événements sont planifiés. Il estdonc possible de les traiter différemment en utilisant cetteconnaissance du futur.
4.1 Maintenances logiciellesavec continuité de service
De gros efforts sont faits de la part des équipementiers pourassurer la continuité de service durant les maintenanceslogicielles. Les approches de mises à jour logicielles sans interrup-tion de service s’appuient à la fois sur la redondance des cartes decommande dans l’équipement et sur ses capacités de routage/ transfert de paquets sans interruption.
Figure 17 – Procédures Graceful Restart pour LDP
Figure 18 – LDP et le TLV Fault Tolerant
La capacité Restart_Cap est envoyée dans les messages RSVP detype Hello (requête et acquittement) pour annoncer l’aptitude d’unrouteur à supporter les extensions GR RSVP en mode restarter . Lerouteur voisin envoie quant à lui un objet de type RecoverLabel aunœud qui redémarre pour reconstruire ses états de commutation(forwarding ), à savoir essentiellement l’ancien label annoncé par lerouteur en cours de redémarrage avant qu’il ne tombe.
Routeur R2Receiving
Routeur R1Restarting
Hello LDP, établissement
Hello LDP, établissement
de la connexion TCP
de la connexion TCP
Initialisation LDP
Initialisation LDP
TLV FT, L = 1
TLV FT, L = 1
TLV FT, L = 1
TLV FT, L = 1
Initialisation LDP
Initialisation LDP
Échange des labels
Échange des labels
Panne du plande commande
« Gel »des entréesde la LFIB
AssociationsFEC-labels gelée(stale )
Démarrage du
timer Recovery
1
2
2
5
7
3
4
6
0
R
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Reservé S A C L
R: Champ FT Reconnect
S: Champ Save State A: indique que tous les labels sont protégés
C: Champ Check-Pointing
L: Champ Learn From Network
par le FT( All-Label Protection Required )
Exemple : si il est nécessaire de désactiver un lien ou un routeur, ilfaudrait idéalement que le routage s’adapte avant l’événement de
manière à ce que le trafic évite les éléments du réseau qui ne serontplus fonctionnels.
-
8/19/2019 Te7585 Haute Disponibilite Dans Les Reseaux IP
13/15
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copieest strictement interdite. – © Editions T.I. TE 7 585 – 13
____________________________________________________________________________________________ HAUTE DISPONIBILITÉ DANS LES RÉSEAUX IP
Le principe générique (figure 19) est de mettre à jour la carte decommande secondaire avec la version désirée Y, d’attendre sasynchronisation avec la carte primaire (à savoir processus protoco-laires, de management, tous les états systèmes nécessaires etpoints de reprise) puis de basculer sans perte de paquets (grâce àNSR ou NSF-GR) vers la carte secondaire qui devient donc active.Il ne reste alors plus qu’à mettre à jour la carte de commande
restée en version X, le tout devant se faire sans incidence sur lescartes d’interface du plan de transfert. En général, lorsque lesystème tournant sous X charge la version Y, il effectue toute unebatterie de vérifications pour valider ou non la compatibilité desversions.
Cela peut paraître simple. Or dans la réalité, il est très difficile desynchroniser des processus qui ne tournent pas avec des versionssimilaires, en fonction des modifications incorporées dans le codeet de leur compatibilité. On distingue de plus les mises à jour quin’ont pas d’incidence sur les processus principaux (appelées misesà jour mineures) et les mises à jour qui impliquent une version dif-férente des processus principaux voire du noyau (appelées mises àjour majeures, qui peuvent nécessiter une mise à jour du firmware
par exemple), dont l’installation perturbe souvent le service surune durée plus longue.
4.2 Maintenances matériellesavec interruption de service
Certaines opérations de maintenance ne permettent pas auxrouteurs de continuer à acheminer des paquets. Il peut s’agir parexemple du remplacement d’une carte d’interface, d’une fibre oud’un équipement de transmission, d’un élément interne au routeurtel que la matrice de commutation ou simplement l’arrêt durouteur. Dans ce cas, les solutions décrites dans le paragraphe 4.1
ne peuvent s’appliquer et il est nécessaire de rerouter les flux afind’éviter le routeur en maintenance.
On peut se contenter de réaliser la maintenance sans précau-tions particulières et laisser les protocoles de routage contournerle routeur comme lors d’une panne imprévue. Dans ce cas, l’inter-ruption de service subie par le client sera égale au MTTR (cf. § 2).
Afin de réduire l’incidence pour le client, il faut provoquer unreroutage des paquets dans le réseau avant l’interruption duservice. La solution à appliquer varie en fonction du protocole deroutage, mais le principe est d’augmenter la métrique (c’est-à-direle coût) du chemin nominal afin que le chemin de secours soit pré-féré. Celui-ci sera donc utilisé à la place du chemin nominal quitraversait l’équipement à arrêter.
Pour les protocoles de routage à état de lien, il suffit d’aug-menter la métrique du ou des liens ne devant plus être utilisés.Cette information de topologie est ensuite naturellement propagée
dans tous les réseaux par le protocole de routage, puis utiliséepour calculer la nouvelle route. Afin d’avoir une incidence totale-ment nulle, il convient également d’utiliser une technique évitantles boucles de routages transitoires [18] lors de la convergencetelle que décrites dans [16] ou [17].
Pour le protocole BGP, utilisant un algorithme à vecteur dechemin, il n’est pas possible de diffuser une information topolo-gique, ni à l’intérieur du réseau (AS) en iBGP et encore moins àl’extérieur du réseau en eBGP. De plus, l’utilisation très communed’équipements de type réflecteur de route peut cacher la route desecours que les routeurs doivent utiliser. En iBGP, on peut déprio-riser le chemin en utilisant l’attribut local_pref mais en eBGP, il n’ya pas actuellement de solution standardisée. De même que pour
les IGP, il convient d’utiliser en complément une technique pouréviter les boucles de routages temporaires. Le plus simple estd’utiliser des tunnels entre les routeurs BGP de bordure, par exem-ple des tunnels MPLS.
5. Conclusion
Les nouveaux services déployés sur les réseaux IP tels que lavoix, les jeux en ligne et la télévision imposent des exigences dedisponibilité de plus en plus fortes aux réseaux IP.
Une première méthode pour améliorer cette disponibilité est lereroutage. Elle consiste, suite à une panne, a rétablir rapidementles communications en contournant l’élément en panne. Cela estréalisé dynamiquement par les protocoles de routage et récem-ment des efforts importants ont été réalisés sur les différentesétapes de la convergence afin d’accélérer le processus et de dimi-nuer les pertes de paquets.
Une seconde méthode consiste à utiliser des fonctions de typehaute disponibilité « HA » qui permettent de masquer les pannesn’affectant que le plan de commande et non le plan de transfert.Cela permet de sécuriser le plan de commande, de redémarrer lesprocessus de routage tout en maintenant la commutation despaquets. Cela évite également un reroutage dans le réseau et doncles échanges protocolaires associés et les impacts sur les autresrouteurs du réseaux. Deux procédés HA sont actuellement enconcurrence le Non Stop Routing et Non Stop Forwarding/Grace- ful Restart . Le premier est un mécanisme interne au routeur alorsque le second nécessite des extensions de tous les protocoles deroutage et donc des dépendances sur les capacités des routeursvoisins. Cependant, les mécanismes HA comportent certainsdésagréments tels que des cas de boucles de routage ou de puitsde trafic en cas de deux pannes simultanées puisque des informa-tions de routage sont maintenues mais plus mises à jour pendantquelque temps. Des boucles sont également susceptibles de surve-nir avec BGP-GR, dans des topologies où seule une partie des voi-sins d’un routeur supporte les extensions Graceful Restart . En
effet, certaines sessions BGP peuvent rester établies ou mainte-nues alors que d’autres non.
D’autres inconvénients sont soulevés, concernant notamment lasupervision de la cohérence globale du routage qui devient plusdifficile à réaliser. Ce n’est pas non plus forcément compatibleavec les solutions de fast-reroute . Enfin, le Non Stop Routing aussibien que le Graceful Restart sont des solutions encore jeunes, peudéployées et sur lesquelles le recul est faible. Les interactions avecla convergence et d’autres mécanismes de détection de pannesdoivent donc être correctement étudiées avant un déploiementdans les réseaux opérationnels afin d’évaluer, pour chaque cas depanne, les mécanismes les plus pertinents qui garantiront une dis-ponibilité maximale.
Figure 19 – Procédure typique pour la mise à jour logiciellesans interruption de service
Carte decommande
activeversion X
Carte decommandesecondaireversion YPlan de
commande
Plan detransfert Cartes d‘interfaces
Basculement
http://-/?-http://-/?-
-
8/19/2019 Te7585 Haute Disponibilite Dans Les Reseaux IP
14/15
HAUTE DISPONIBILITÉ DANS LES RÉSEAUX IP
____________________________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copieest strictement interdite. – © Editions T.I.TE 7 585 – 14
BGP Graceful Restart
BFD
Disponibilité
FT
GR
Graceful Restart
Hello
IGP
IS-IS Graceful Restart
LDP Graceful Restart
Maintenance
MTTF
MTTR
Non Stop Forwarding
Non Stop Routing
OSPF Graceful Restart
PannePanne
Reroutage
RSVP Graceful Restart
AS
en
BFD
en
BGP
en
COS
en
EGP
en
FEC
en
FIB
en
GR
en
HA
en
IETF
en
IGP
en
IS-IS
enISSU
en
LDP
en
LER
en
LFIB
en
LSA
-
8/19/2019 Te7585 Haute Disponibilite Dans Les Reseaux IP
15/15
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copieest strictement interdite. – © Editions T.I. TE 7 585 – 15
____________________________________________________________________________________________ HAUTE DISPONIBILITÉ DANS LES RÉSEAUX IP
en
LSP
en
LSR
en
MP-BGP
en
MPLS
en
MTBF
en
MTTF
en
MTTR
en
NSF
en
NSR
en
OSPF
en
PE
en
QOS
en
RIB
en
RIP
en
RP
en
TLV
en
VPN
en
VRF
en