Download pdf - Te7585 Haute Disponibilite Dans Les Reseaux IP

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


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://-/?-


3/15


____________________________________________________________________________________________ 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://-/?-


4/15


____________________________________________________________________________________________


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



5/15



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://-/?-


6/15


____________________________________________________________________________________________


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.



7/15



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/15


____________________________________________________________________________________________


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é restarting 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://-/?-


9/15



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 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://-/?-


10/15


____________________________________________________________________________________________


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 restarting 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 .


11/15



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://-/?-


12/15


____________________________________________________________________________________________


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


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.


13/15



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://-/?-


14/15


____________________________________________________________________________________________


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


15/15



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