RIP, faut pas trop en demander ...

Ce chapitre va sans doute bousculer un peu le protocole. Vous risquez à la fin de vous dire que je ne l'aime pas, que finalement c'est du bas de gamme tout juste bon à reléguer au musée ... C'est faux ! RIP est un très bon protocole, il sera capable de couvrir encore de nombreux besoins actuels et on pourra très bien le mettre en oeuvre sur de grands et beaux réseaux. Mais pour bien l'utiliser il est important de savoir ce qu'il peut faire et où sont ses limites !

RIP ! Tu comptes à l'infini !

Dans le chapitre précédent, une subtilité aura sans doute échappé aux moins aguerris d'entre-vous ! En effet, nous sommes parti du postulat que tous les routeurs émettaient leurs updates en même temps ! Quelle erreur ! Certes, ils émettent leurs updates toutes les 30 secondes, mais le t0 de départ peut très bien être décalé d'un routeur à un autre, ne serait-ce que parce que vous ne les aurez pas mis sous tension tous exactement au même moment !

Nous savons que RIP considére qu'une route ayant un coût supérieur à 15, soit donc 16 sauts, est inutilisable. En conséquence un routeur transmet une information d'inaccessiblité en affectant un coût de 16 à une route.

Enfin, sachez qu'un routeur inscrit une route en Possibly Down lorsqu'il reçoit une information d'inaccessibilité pour cette route. Ces concepts seront expliqués dans le paragraphe suivant.

Dans notre réseau exemple (désormais habituel), en situation nominale, 10.0.0.0 est connu :

• de R2 et R3 en 1 sauts via R1
• de R4 en 2 sauts via R2
• de R1 comme directement raccordé à son interface E0.

Examinons le comportement du protocole si R1 transmet à R2 et R3 une information d'inaccessiblité (coût de 16) pour le réseau 10.0.0.0 (son interface E0 étant par exemple HS) :

• Tout d'abord R1 émet un update : à réception de l'update de R1, R2 et R3 mettent à jour leurs tables pour la route 10.0.0.0 en lui affectant un coût de 16. En effet, dans leurs tables c'était R1 qui contrôlait le coût de la route vers 10.0.0.0. Comme R1 a modifié son coût, R2 et R3 s'alignent sur le nouveau coût.
• Puis R4, 15 secondes plus tard, émet son update : R2 et R3 reçoivent de R4 une information selon laquelle 10.0.0.0 est connu de R4 en 2 sauts ! Ce coût étant meilleur que celui de 16 annoncé par R1, R2 et R3 incrémentent de 1 le coût annoncé par R4 et initialisent une nouvelle route pour 10.0.0.0 via R4 en 3 sauts !
• Puis, 5 secondes après R4, R2 et R3 émettent un update : R4 et R1 reçoivent donc une information selon laquelle ils peuvent atteindre 10.0.0.0 en 3 sauts. Donc R1 prend cette information pour argent comptant et initialise une entrée dans sa table pour 10.0.0.0 via R2 en 4 sauts (il choisi ici R2 mais aurait pu choisir R3 !). R4, quand à lui, va modifier le coût de sa route pour 10.0.0.0 en 4 sauts. En effet, c'est R2 qui contrôle le coût de sa route pour 10.0.0.0 !!
• Dans un update suivant, R4 renverra à R2 et R3 un coût de 4 pour 10.0.0.0. Ceux-ci enregistreront la modification de coût et afficheront 5 pour cette route puisque c'est R4 qui contrôle le coût de route ...

Il y aura donc ainsi un rebond entre R2-R3 et R4 jusqu'à ce que la route atteigne un coût de 16 et soit donc déclarée inaccessible dans tous les routeurs ! C'est ce que l'on appelle le Count to Infinity (comptage à l'infini !). L'animation suivante démontre qu'il faudra environ au total 19 échanges d'updates, répartis sur 4 minutes 30 secondes environ, entre R2-R3, R1 et R4 pour que le réseau 10.0.0.0 soit bien déclaré inaccessible dans tous les routeurs !

Il était difficile de schématiser le processus précédemment décrit sur des images fixes ou même en gif animé. Je vous propose donc cette animation Flash. Il est nécessaire que votre navigateur soit équipé du plug-in Flash 4 au minimum pour la lire. L'animation étant peut-être un peu rapide, vous disposez de boutons "Pause" et "Lecture" pour en contrôler le déroulement.

Avouons que ce n'est pas un fonctionnement optimum ! Le plus grave est que si du trafic pour 10.0.0.0 est émis dans le réseau, il va rebondir entre R2-R3 et R4 jusqu'à ce que les tables de routages soient bien alignées ! Cependant, à cause de ces rebonds, la charge des routeurs va monter en flèche jusqu'à éventuellement les rendre hors service ou, pour le moins, bloquer l'acheminement de tout le trafic. Or, dans ce trafic, sont incorporés les updates qui doivent justement mettre à jour ces tables ! Le délai de mise à jour sera d'autant plus long et au final vous aurez un réseau partiellement HS !

Rassurez-vous, les concepteurs du protocole ont bien vu le problème (ils ne sont pas neu-neu tout de même !). Dans notre exemple, le problème vient du fait que R4 envoie une information à R2 et R3 d'une route potentiellement meilleure pour 10.0.0.0 ! Or la route pour 10.0.0.0 de R4 passe par R2-R3 ! Pourquoi donc informer R2 et R3 ? Il n'y a aucune raison valable ...

Plus généralement un routeur ne devrait pas réémettre une information de route à un routeur par qui il l'a apprise ! Si R4 ne parle pas de 10.0.0.0 à R2 et R3, il n'y aura pas de comptage à l'infini ! R2 et R3 ne remplacerons pas la route 10.0.0.0 via R1 ayant un coût de 16 par une fausse route via R4 ayant un coût de 3 !

Il existe deux solutions possibles :

• la première est que les routeurs ne réémettent pas les informations sur les interfaces par lesquelles ils les ont apprises. Cette technique s'appelle le split horizon (ne me demandez pas pourquoi !).
• la deuxième est que les routeurs réémettent les informations sur les interfaces par lesquelles ils les ont apprises, mais en leur affectant un coût de 16. Cette technique s'appelle le poison reverse (ne me demandez pas pourquoi non plus !).

Selon les implémentations du protocole par les différents constructeurs de routeurs on pourra trouver une méthode ou l'autre pour combattre le count to infinity. Chez Cisco, à priori, le poison reverse a la préférence, mais par un jeu de commande on peut cependant activer le split horizon. Sincérement je ne vois pas l'intérêt du poison reverse ! Il augmente la taille des updates sans apparemment aucune raison ! Je serai donc tenté de préférer le split horizon ! Si l'un d'entre-vous à un exemple qui permette de clairement favoriser le poison reverse, je suis à son écoute ...

L'animation suivante, vous présente donc le même scénario de mise à jour des tables de routage que précédemment mais en implémentant le split horizon :

Vous aurez remarqué en fin d'animation que les routeurs attendent 2 minutes avant de supprimer le réseau 10.0.0.0 de leurs tables de routage. Ce phénomène est expliqué dans le paragraphe suivant.

Convergence ! Que tu es lente ...

La convergence est la capacité du protocole à réaligner toutes les tables de routage lors d'un changement d'état dans le réseau. Ce changement peut être de natures diverses : lien d'interconnexion ou routeur HS, interface de routeur HS, ajoût ou suppression d'un réseau IP ou d'un site, etc. Quel qu'il soit, ce changement implique une modification des déclarations des réseaux dans les différentes tables de routage. Selon la nature du changement le protocole aura un comportement différent. Pour comprendre pourquoi je dis que la convergence est lente, il faut comprendre ce qui se passe en cas de modification de la configuration du réseau. C'est le but des paragraphes suivants.

Le cas du support Hors Service

Si un support (un lien d'interconnexion ou un LAN) est détecté HS (dans le cas du LAN ce n'est pas vraiment évident, mais admettons !) :

• tous les routeurs directement raccordés au support détectent physiquement (perte de porteuse ou de signal électrique généralement) sa perte.
• ils modifient l'état du réseau IP correspondant dans leur table de routage et le mettent en Possibly Down (Peut-être HS) puis ils envoient l'information aux autres routeurs au prochain update (30 secondes plus tard !) en plaçant le coût de la route à 16 !
• ils attendent ensuite pendant l'équivalent de 4 updates (2 minutes) avant de considérer réellement le réseau HS
• si au bout de ces 2 minutes le réseau support n'est pas revenu à la normale, ils valident une éventuelle route secondaire ignorée lors de précédents updates car présentant un coût plus important que la route nominale.
• si le réseau remonte avant 2 minutes, le routeur d'accès valide de nouveau la route initiale, replace son coût à 0, et réenvoie l'information de coût 0 à tous ses voisins dans le prochain update !

Le pire c'est que ça continue, encore ! Lorsqu'un routeur reçoit une information selon laquelle une destination est inaccessible (coût de 16), il passe le réseau en Possibly Down (coût de 16) dans sa table, transmets l'information aux autres au prochain update et attend également 2 minutes avant de valider une potentielle nouvelle route.

Au final, si vous sommez les délais d'émission d'updates qui obligent à attendre au minimum 30 secondes avant de transmettre l'information aux voisins, avec le délai d'attente de 2 minutes qui est décalé d'au minimum 30 secondes d'un routeur à l'autre à cause du délai de retransmission des updates, c'est long ! Un petit calcul sur notre réseau exemple :

Supposons que le réseau 10.0.0.0 passe HS juste après émission d'un update où il était déclaré valide. Ce moment sera appelé t0.

• R1 déclare 10.0.0.0 Possibly Down dans sa table de routage et enclenche son timer (pour information ce timer est appelé : Hold-time timer, quand une route est suspendu elle est placé dans le Garbage Collection, ne me demandait pas pourquoi un nom si barbare !)
• A t0+30", R1 informe R2 et R3 que 10.0.0.0 est inaccessible en plaçant un coût de 16 dans l'update
• R2 et R3 placent le réseau 10.0.0.0 Possibly Down à t0+30" dans leur table et enclenchent leurs timers
• A t0+60", R2 et R3 informent R4 que 10.0.0.0 est HS.
• R4 déclare 10.0.0.0 Possibly Down et enclenche donc son timer (il est t0+60")
• A t0 + 2', R1 pourrait valider une nouvelle route éventuelle (s'il en existait une ! Ce qui n'est pas le cas dans notre exemple !). Il diffusera cette route au prochain update vers R2 et R3. Ceux-ci n'en tiendront pas compte car ils sont toujours en Garbage Collection pour cette destination.
• R2 et R3 valideront cette éventuelle nouvelle route annoncée par R1 à t0 + 2'30", puis transmettront l'update de mise à jour à R4 que lui-même ne validera qu'à t0+3'.

Bref ! Si votre réseau aligne 10 routeurs sur une route, il faudra au minimum 2'+(10*30") = 7 minutes pour réaligner vos tables ! Bon courage ! Vous avez dit délai de convergence long ?

Le cas du routeur Hors Service

Si un routeur est HS le cas est différent, car cette fois-ci il n'y a pas de déclaration d'inaccessibilité par un coût de 16 dans un update ! Le problème est que les voisins du routeur ne reçoivent plus d'update de ce routeur ! Certaines routes ne sont donc plus annoncées ! Les routeurs voisins n'ont aucun moyen de savoir si un pair est HS car aucune connexion n'est établie entre eux. C'est l'absence de mise à jour (on parle de rafraîchissement des tables) des routes précédemment annoncées qui déclenchera la mise à jour.

Chaque routeur, je l'ai indiqué précédemment, enclenche un timer lorsqu'il initialise une entrée contenue dans un update. Chaque fois que cette entrée est de nouveau annoncée par un update, le timer est remis à 0. Si le timer n'est pas raffraichi pendant 6 updates consécutifs (3 minutes), la destination est déclarée Possibly Down comme précédemment.

Toujours comme précédemment, le routeur garde cette route dans l'état Possibly Down pendant 2 minutes (4 updates) avant de la déclarer réellement HS et de valider une éventuelle route de secours.

Dans notre réseau exemple, si R1 passe hors tension ou rencontre un problème logiciel qui le rend inopérant, le réseau 10.0.0.0 n'est plus annoncé à R2 et R3. Ceux-ci attendront donc 5 minutes (3 minutes + 2 minutes) avant de déclarer le réseau HS dans leurs tables. Mais ils informeront R4 du problème par un coût de 16 sur la route 10.0.0.0 quand la destination sera passée en Possibly Down dans leurs tables, soit donc au bout de 3 minutes ! Dans le détail, supposons que R1 passe HS juste après avoir émis un update normal à R2 et R3. Ce moment sera appelé t0 :

• R2 et R3 ne reçoivent donc plus d'updates de R1 ensuite.
• R2 et R3 déclare 10.0.0.0 Possibly Down dans leur table de routage à t0+3' (6 updates plus tard) et enclenchent leurs hold-time timers.
• A t0+3'30", R2 et R3 informe R4 que 10.0.0.0 est inaccessible en plaçant un coût de 16 dans l'update à destination de R4.
• R4 placent donc le réseau 10.0.0.0 Possibly Down à t0+3'30" (à réception de l'update de R2 et R3) dans sa table et enclenchent son hold-time timer.
• A t0+5', R2 et R3 n'ayant pas reçu de nouvel update pour 10.0.0.0 suppriment la route de leurs tables de routage et ne l'émettent plus vers R4.
• R4 ne recevant plus d'updates contenant 10.0.0.0 de la part de R2 et R3, supprime 10.0.0.0 de sa table à t0+5'30".

Donc, comme précédemment, si votre réseau aligne 10 routeurs sur une route, il faudra au minimum 5'+(10*30") = 10 minutes pour réaligner vos tables ! Encore une fois on peut dire que RIP n'est pas un modèle de rapidité !

Pourquoi ?

J'en vois qui se grattent la tête ! Mais pourquoi attendre 2 minutes dans un cas ou 5 minutes dans un autre avant de valider une nouvelle route ? Pour au moins deux raisons :

• Pour ne pas mettre en péril la stabilité du réseau ! Si chaque fois qu'il y a une micro-coupure sur un support les routeurs entamaient une reconfiguration immédiate du réseau nous aurions des tables de routage qui joueraient au yo-yo !!
• Pour laisser le temps aux routeurs voisins de bloquer leurs tables pour la destination indisponible. Car si on ne temporisait pas la reconfiguration on risquerait d'obtenir des boucles de routage dans le réseau, ce qui n'est franchement pas bien !

Croyez-moi sur parole, il vaut mieux prendre un peu de temps pour rien que de mettre l'ensemble du réseau par terre !!