{"id":476,"date":"2017-04-26T14:50:51","date_gmt":"2017-04-26T12:50:51","guid":{"rendered":"http:\/\/www.gatoux.com\/?page_id=476"},"modified":"2017-04-29T13:32:32","modified_gmt":"2017-04-29T11:32:32","slug":"limites-de-rip","status":"publish","type":"page","link":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/limites-de-rip\/","title":{"rendered":"Limites de RIP"},"content":{"rendered":"<p>Ce chapitre va sans doute bousculer un peu le protocole. Vous risquez \u00e0 la fin de vous dire que je ne l&rsquo;aime pas, que finalement c&rsquo;est du bas de gamme tout juste bon \u00e0 rel\u00e9guer au mus\u00e9e &#8230; C&rsquo;est faux ! RIP est un tr\u00e8s bon protocole, il sera capable de couvrir encore de nombreux besoins actuels et on pourra tr\u00e8s bien le mettre en \u0153uvre sur de grands et beaux r\u00e9seaux. Mais pour bien l&rsquo;utiliser il est important de savoir ce qu&rsquo;il peut faire et o\u00f9 sont ses limites !<\/p>\n<h2>RIP ! Tu comptes \u00e0 l&rsquo;infini !<\/h2>\n<p>Dans le chapitre pr\u00e9c\u00e9dent, une subtilit\u00e9 aura sans doute \u00e9chapp\u00e9 aux moins aguerris d&rsquo;entre-vous ! En effet, nous sommes parti du postulat que tous les routeurs \u00e9mettaient leurs updates en m\u00eame temps ! Quelle erreur ! Certes, ils \u00e9mettent leurs updates toutes les 30 secondes, mais le t0 de d\u00e9part peut tr\u00e8s bien \u00eatre d\u00e9cal\u00e9 d&rsquo;un routeur \u00e0 un autre, ne serait-ce que parce que vous ne les aurez pas mis sous tension tous exactement au m\u00eame moment !<\/p>\n<p>Nous savons que RIP consid\u00e8re qu&rsquo;une route ayant un co\u00fbt sup\u00e9rieur \u00e0 15, soit donc 16 sauts, est inutilisable. En cons\u00e9quence <strong>un routeur transmet une information d\u2019inaccessibilit\u00e9 en affectant un co\u00fbt de 16 \u00e0 une route<\/strong>.<\/p>\n<p>Enfin, sachez qu&rsquo;un routeur inscrit une route en <strong>Possibly Down<\/strong> lorsqu&rsquo;il re\u00e7oit une information d&rsquo;inaccessibilit\u00e9 pour cette route. Ces concepts seront expliqu\u00e9s dans le paragraphe suivant.<\/p>\n<p>Dans notre r\u00e9seau exemple (<em>d\u00e9sormais habituel<\/em>), en situation nominale, <strong>10.0.0.0<\/strong> est connu :<\/p>\n<ul>\n<li>de <strong>R2<\/strong> et <strong>R3<\/strong> en 1 sauts via R1<\/li>\n<li>de <strong>R4<\/strong> en 2 sauts via R2<\/li>\n<li>de <strong>R1<\/strong> comme directement raccord\u00e9 \u00e0 son interface E0.<\/li>\n<\/ul>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-262 aligncenter\" src=\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/RIP5.gif\" alt=\"\" width=\"450\" height=\"312\" \/><\/p>\n<p>Examinons le comportement du protocole si R1 transmet \u00e0 R2 et R3 une information d&rsquo;inaccessiblit\u00e9 (<em>co\u00fbt de 16<\/em>) pour le r\u00e9seau 10.0.0.0 (<em>son interface E0 \u00e9tant par exemple HS<\/em>) :<\/p>\n<ul>\n<li>Tout d&rsquo;abord <strong>R1 \u00e9met un update<\/strong> : \u00e0 r\u00e9ception de l&rsquo;update de <strong>R1, R2 et R3<\/strong> mettent \u00e0 jour leurs tables pour la <strong>route 10.0.0.0 en lui affectant un co\u00fbt de 16<\/strong>. En effet, dans leurs tables c&rsquo;\u00e9tait R1 qui contr\u00f4lait le co\u00fbt de la route vers 10.0.0.0. Comme R1 a modifi\u00e9 son co\u00fbt, R2 et R3 s&rsquo;alignent sur le nouveau co\u00fbt.<\/li>\n<li><strong>Puis R4<\/strong>, 15 secondes plus tard, <strong>\u00e9met son update<\/strong> : R2 et R3 re\u00e7oivent de R4 une information selon laquelle 10.0.0.0 est connu de R4 en 2 sauts ! Ce co\u00fbt \u00e9tant meilleur que celui de 16 annonc\u00e9 par <strong>R1, R2 et R3 incr\u00e9mentent de 1 le co\u00fbt annonc\u00e9 par R4 et initialisent une nouvelle route pour 10.0.0.0 via R4 en 3 sauts<\/strong> !<\/li>\n<li>Puis, 5 secondes apr\u00e8s <strong>R4, R2 et R3 \u00e9mettent un update<\/strong> : R4 et R1 re\u00e7oivent donc une information selon laquelle ils peuvent atteindre 10.0.0.0 en 3 sauts. Donc <strong>R1 prend cette information pour argent comptant et initialise une entr\u00e9e dans sa table pour 10.0.0.0 via R2 en 4 sauts<\/strong> (<em>il choisi ici R2 mais aurait pu choisir R3 !<\/em>). <strong>R4<\/strong>, quand \u00e0 lui, <strong>va modifier le co\u00fbt de sa route pour 10.0.0.0 en 4 sauts<\/strong>. En effet, c&rsquo;est R2 qui contr\u00f4le le co\u00fbt de sa route pour 10.0.0.0 !!<\/li>\n<li>Dans un update suivant, <strong>R4 renverra \u00e0 R2 et R3 un co\u00fbt de 4 pour 10.0.0.0<\/strong>. Ceux-ci enregistreront la modification de co\u00fbt et afficheront 5 pour cette route puisque c&rsquo;est R4 qui contr\u00f4le le co\u00fbt de route &#8230;<\/li>\n<\/ul>\n<p>Il y aura donc ainsi un <strong>rebond entre R2-R3 et R4 jusqu&rsquo;\u00e0 ce que la route atteigne un co\u00fbt de 16<\/strong> et soit donc d\u00e9clar\u00e9e inaccessible dans tous les routeurs ! C&rsquo;est ce que l&rsquo;on appelle le <strong>Count to Infinity<\/strong> (<em>comptage \u00e0 l&rsquo;infini !<\/em>). L&rsquo;animation suivante d\u00e9montre qu&rsquo;il faudra environ au total 19 \u00e9changes d&rsquo;updates, r\u00e9partis sur 4 minutes 30 secondes environ, entre R2-R3, R1 et R4 pour que le r\u00e9seau 10.0.0.0 soit bien d\u00e9clar\u00e9 inaccessible dans tous les routeurs !<\/p>\n<p>Il \u00e9tait difficile de sch\u00e9matiser le processus pr\u00e9c\u00e9demment d\u00e9crit sur des images fixes ou m\u00eame en gif anim\u00e9. Je vous propose donc cette petite animation au format YouTube ! . Il s&rsquo;agit d&rsquo;une ancienne animation Flash convertie en vid\u00e9o, le bouton Pause \u00e0 l&rsquo;int\u00e9rieur de la vid\u00e9o ne fonctionne donc plus mais vous pouvez utiliser les fonctionnalit\u00e9s du lecteur YouTube pour stopper l&rsquo;animation si elle est trop rapide.<\/p>\n<p style=\"text-align: left; padding-left: 90px;\">\n<div class=\"youtube-embed\" itemprop=\"video\" itemscope itemtype=\"https:\/\/schema.org\/VideoObject\">\n\t<meta itemprop=\"url\" content=\"https:\/\/www.youtube.com\/v\/hzN-4MRnqGQ\" \/>\n\t<meta itemprop=\"name\" content=\"Limites de RIP\" \/>\n\t<meta itemprop=\"description\" content=\"Limites de RIP\" \/>\n\t<meta itemprop=\"uploadDate\" content=\"2017-04-26T14:50:51+02:00\" \/>\n\t<meta itemprop=\"thumbnailUrl\" content=\"https:\/\/i.ytimg.com\/vi\/hzN-4MRnqGQ\/default.jpg\" \/>\n\t<meta itemprop=\"embedUrl\" content=\"https:\/\/www.youtube.com\/embed\/hzN-4MRnqGQ\" \/>\n\t<meta itemprop=\"height\" content=\"340\" \/>\n\t<meta itemprop=\"width\" content=\"560\" \/>\n\t<iframe loading=\"lazy\" style=\"border: 0;\" class=\"youtube-player\" width=\"560\" height=\"340\" src=\"https:\/\/www.youtube.com\/embed\/hzN-4MRnqGQ\" allowfullscreen><\/iframe>\n<\/div>\n<\/p>\n<p align=\"center\">Avouons que ce n&rsquo;est pas un fonctionnement optimum ! Le plus grave est que si du trafic pour 10.0.0.0 est \u00e9mis dans le r\u00e9seau, il va rebondir entre R2-R3 et R4 jusqu&rsquo;\u00e0 ce que les tables de routages soient bien align\u00e9es ! Cependant, \u00e0 cause de ces rebonds, la charge des routeurs va monter en fl\u00e8che jusqu&rsquo;\u00e0 \u00e9ventuellement les rendre hors service ou, pour le moins, bloquer l&rsquo;acheminement de tout le trafic. Or, dans ce trafic, sont incorpor\u00e9s les updates qui doivent justement mettre \u00e0 jour ces tables ! Le d\u00e9lai de mise \u00e0 jour sera d&rsquo;autant plus long et au final vous aurez un r\u00e9seau partiellement HS !<\/p>\n<p align=\"center\">Rassurez-vous, les concepteurs du protocole ont bien vu le probl\u00e8me (<em>ils ne sont pas neu-neu tout de m\u00eame !<\/em>). Dans notre exemple, le probl\u00e8me vient du fait que R4 envoie une information \u00e0 R2 et R3 d&rsquo;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&rsquo;y a aucune raison valable &#8230;<\/p>\n<p align=\"center\">Plus g\u00e9n\u00e9ralement un routeur ne devrait pas r\u00e9\u00e9mettre une information de route \u00e0 un routeur par qui il l&rsquo;a apprise ! Si R4 ne parle pas de 10.0.0.0 \u00e0 R2 et R3, il n&rsquo;y aura pas de comptage \u00e0 l&rsquo;infini ! R2 et R3 ne remplacerons pas la route 10.0.0.0 via R1 ayant un co\u00fbt de 16 par une fausse route via R4 ayant un co\u00fbt de 3 !<\/p>\n<p style=\"text-align: left;\" align=\"center\">Il existe deux solutions possibles :<\/p>\n<ul style=\"text-align: left;\">\n<li>\n<div align=\"left\">la premi\u00e8re est que <strong>les routeurs ne r\u00e9\u00e9mettent pas les informations sur les interfaces par lesquelles ils les ont apprises<\/strong>. Cette technique s&rsquo;appelle le <strong>split horizon<\/strong> (<em>ne me demandez pas pourquoi !<\/em>).<\/div>\n<\/li>\n<li>\n<div align=\"left\">la deuxi\u00e8me est que <strong>les routeurs r\u00e9\u00e9mettent les informations sur les interfaces par lesquelles ils les ont apprises, mais en leur affectant un co\u00fbt de 16<\/strong>. Cette technique s&rsquo;appelle le <strong>poison reverse<\/strong> (<em>ne me demandez pas pourquoi non plus !<\/em>).<\/div>\n<\/li>\n<\/ul>\n<p style=\"text-align: left;\" align=\"center\">Selon les impl\u00e9mentations du protocole par les diff\u00e9rents constructeurs de routeurs on pourra trouver une m\u00e9thode ou l&rsquo;autre pour combattre le \u00ab\u00a0count to infinity\u00a0\u00bb. Chez Cisco, \u00e0 priori, le poison reverse a la pr\u00e9f\u00e9rence, mais par un jeu de commande on peut cependant activer le split horizon. Sinc\u00e8rement je ne vois pas l&rsquo;int\u00e9r\u00eat du \u00ab\u00a0poison reverse\u00a0\u00bb ! Il augmente la taille des updates sans apparemment aucune raison ! <strong>Je serai donc tent\u00e9 de pr\u00e9f\u00e9rer le \u00ab\u00a0split horizon\u00a0\u00bb<\/strong> ! Si l&rsquo;un d&rsquo;entre-vous \u00e0 un exemple qui permette de clairement favoriser le poison reverse, je suis \u00e0 son \u00e9coute &#8230;<\/p>\n<p style=\"text-align: left;\" align=\"center\">L&rsquo;animation suivante, vous pr\u00e9sente donc le m\u00eame sc\u00e9nario de mise \u00e0 jour des tables de routage que pr\u00e9c\u00e9demment mais en impl\u00e9mentant le \u00ab\u00a0split horizon\u00a0\u00bb :<\/p>\n\n<div class=\"youtube-embed\" itemprop=\"video\" itemscope itemtype=\"https:\/\/schema.org\/VideoObject\">\n\t<meta itemprop=\"url\" content=\"https:\/\/www.youtube.com\/v\/3xNdaX0VXP4\" \/>\n\t<meta itemprop=\"name\" content=\"Limites de RIP\" \/>\n\t<meta itemprop=\"description\" content=\"Limites de RIP\" \/>\n\t<meta itemprop=\"uploadDate\" content=\"2017-04-26T14:50:51+02:00\" \/>\n\t<meta itemprop=\"thumbnailUrl\" content=\"https:\/\/i.ytimg.com\/vi\/3xNdaX0VXP4\/default.jpg\" \/>\n\t<meta itemprop=\"embedUrl\" content=\"https:\/\/www.youtube.com\/embed\/3xNdaX0VXP4\" \/>\n\t<meta itemprop=\"height\" content=\"340\" \/>\n\t<meta itemprop=\"width\" content=\"560\" \/>\n\t<iframe loading=\"lazy\" style=\"border: 0;\" class=\"youtube-player\" width=\"560\" height=\"340\" src=\"https:\/\/www.youtube.com\/embed\/3xNdaX0VXP4\" allowfullscreen><\/iframe>\n<\/div>\n\n<p>Vous aurez remarqu\u00e9 en fin d&rsquo;animation que les routeurs attendent 2 minutes avant de supprimer le r\u00e9seau 10.0.0.0 de leurs tables de routage. Ce ph\u00e9nom\u00e8ne est expliqu\u00e9 dans le paragraphe suivant.<\/p>\n<h2>Convergence ! Que tu es lente &#8230;<\/h2>\n<p>La convergence est la capacit\u00e9 du protocole \u00e0 r\u00e9aligner toutes les tables de routage lors d&rsquo;un changement d&rsquo;\u00e9tat dans le r\u00e9seau. Ce changement peut \u00eatre de natures diverses : lien d&rsquo;interconnexion ou routeur HS, interface de routeur HS, ajout ou suppression d&rsquo;un r\u00e9seau IP ou d&rsquo;un site, etc. Quel qu&rsquo;il soit, ce changement implique une modification des d\u00e9clarations des r\u00e9seaux dans les diff\u00e9rentes tables de routage. Selon la nature du changement le protocole aura un comportement diff\u00e9rent. 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\u00e9seau. C&rsquo;est le but des paragraphes suivants.<\/p>\n<h3>Le cas du support Hors Service<\/h3>\n<p style=\"padding-left: 30px;\">Si un support (<em>un lien d&rsquo;interconnexion ou un LAN<\/em>) est d\u00e9tect\u00e9 HS (<em>dans le cas du LAN ce n&rsquo;est pas vraiment \u00e9vident, mais admettons !<\/em>) :<\/p>\n<ul>\n<li>tous les routeurs directement raccord\u00e9s au support d\u00e9tectent physiquement (<em>perte de porteuse ou de signal \u00e9lectrique g\u00e9n\u00e9ralement<\/em>) sa perte.<\/li>\n<li>ils modifient l&rsquo;\u00e9tat du r\u00e9seau IP correspondant dans leur table de routage et le mettent en <strong>Possibly Down<\/strong> (<em>Peut-\u00eatre HS<\/em>) puis ils envoient l&rsquo;information aux autres routeurs au prochain update (<em>30 secondes plus tard !<\/em>) en pla\u00e7ant le co\u00fbt de la route \u00e0 16 !<\/li>\n<li>ils attendent ensuite pendant l&rsquo;\u00e9quivalent de 4 updates (<em>2 minutes<\/em>) avant de consid\u00e9rer r\u00e9ellement le r\u00e9seau HS<\/li>\n<li>si au bout de ces 2 minutes le r\u00e9seau support n&rsquo;est pas revenu \u00e0 la normale, ils valident une \u00e9ventuelle route secondaire ignor\u00e9e lors de pr\u00e9c\u00e9dents updates car pr\u00e9sentant un co\u00fbt plus important que la route nominale.<\/li>\n<li>si le r\u00e9seau remonte avant 2 minutes, le routeur d&rsquo;acc\u00e8s valide de nouveau la route initiale, replace son co\u00fbt \u00e0 0, et r\u00e9envoie l&rsquo;information de co\u00fbt 0 \u00e0 tous ses voisins dans le prochain update !<\/li>\n<\/ul>\n<p style=\"padding-left: 30px;\">Le pire c&rsquo;est que \u00e7a continue, encore ! Lorsqu&rsquo;un routeur re\u00e7oit une information selon laquelle une destination est inaccessible (<em>co\u00fbt de 16<\/em>), il passe le r\u00e9seau en <strong>Possibly Down<\/strong> (co\u00fbt de 16) dans sa table, transmets l&rsquo;information aux autres au prochain update et attend \u00e9galement 2 minutes avant de valider une potentielle nouvelle route.<\/p>\n<p style=\"padding-left: 30px;\">Au final, si vous sommez les d\u00e9lais d&rsquo;\u00e9mission d&rsquo;updates qui obligent \u00e0 attendre au minimum 30 secondes avant de transmettre l&rsquo;information aux voisins, avec le d\u00e9lai d&rsquo;attente de 2 minutes qui est d\u00e9cal\u00e9 d&rsquo;au minimum 30 secondes d&rsquo;un routeur \u00e0 l&rsquo;autre \u00e0 cause du d\u00e9lai de retransmission des updates, c&rsquo;est long ! Un petit calcul sur notre r\u00e9seau exemple :<\/p>\n<p style=\"padding-left: 30px;\">Supposons que le r\u00e9seau 10.0.0.0 passe HS juste apr\u00e8s \u00e9mission d&rsquo;un update o\u00f9 il \u00e9tait d\u00e9clar\u00e9 valide. Ce moment sera appel\u00e9 t0.<\/p>\n<ul>\n<li>R1 d\u00e9clare 10.0.0.0 <strong>Possibly Down<\/strong> dans sa table de routage et enclenche son timer (<em>pour information ce timer est appel\u00e9<\/em> : <strong>Hold-time timer<\/strong>, <em>quand une route est suspendu elle est plac\u00e9 dans le<\/em> <strong>Garbage Collection<\/strong>, <em>ne me demandait pas pourquoi un nom si barbare !<\/em>)<\/li>\n<li>A t0+30&Prime;, R1 informe R2 et R3 que 10.0.0.0 est inaccessible en pla\u00e7ant un co\u00fbt de 16 dans l&rsquo;update<\/li>\n<li>R2 et R3 placent le r\u00e9seau 10.0.0.0 <strong>Possibly Down<\/strong> \u00e0 t0+30&Prime; dans leur table et enclenchent leurs timers<\/li>\n<li>A t0+60&Prime;, R2 et R3 informent R4 que 10.0.0.0 est HS.<\/li>\n<li>R4 d\u00e9clare 10.0.0.0 Possibly Down et enclenche donc son timer (il est t0+60&Prime;)<\/li>\n<li>A t0 + 2&prime;, R1 pourrait valider une nouvelle route \u00e9ventuelle (<em>s&rsquo;il en existait une ! Ce qui n&rsquo;est pas le cas dans notre exemple !<\/em>). Il diffusera cette route au prochain update vers R2 et R3. Ceux-ci n&rsquo;en tiendront pas compte car ils sont toujours en <strong>Garbage Collection<\/strong> pour cette destination.<\/li>\n<li>R2 et R3 valideront cette \u00e9ventuelle nouvelle route annonc\u00e9e par R1 \u00e0 t0 + 2&rsquo;30\u00a0\u00bb, puis transmettront l&rsquo;update de mise \u00e0 jour \u00e0 R4 que lui-m\u00eame ne validera qu&rsquo;\u00e0 t0+3&prime;.<\/li>\n<\/ul>\n<p style=\"padding-left: 30px;\">Bref ! Si votre r\u00e9seau aligne 10 routeurs sur une route, il faudra au minimum 2&rsquo;+(10*30&Prime;) = 7 minutes pour r\u00e9aligner vos tables ! Bon courage ! <strong>Vous avez dit d\u00e9lai de convergence long ?<\/strong><\/p>\n<h3>Le cas du routeur Hors Service<\/h3>\n<p style=\"padding-left: 30px;\">Si un routeur est HS le cas est diff\u00e9rent, car cette fois-ci il n&rsquo;y a pas de d\u00e9claration d&rsquo;inaccessibilit\u00e9 par un co\u00fbt de 16 dans un update ! Le probl\u00e8me est que les voisins du routeur ne re\u00e7oivent plus d&rsquo;update de ce routeur ! Certaines routes ne sont donc plus annonc\u00e9es ! Les routeurs voisins n&rsquo;ont aucun moyen de savoir si un pair est HS car aucune connexion n&rsquo;est \u00e9tablie entre eux. C&rsquo;est l&rsquo;absence de mise \u00e0 jour (<em>on parle de rafra\u00eechissement des tables<\/em>) des routes pr\u00e9c\u00e9demment annonc\u00e9es qui d\u00e9clenchera la mise \u00e0 jour.<\/p>\n<p style=\"padding-left: 30px;\">Chaque routeur, je l&rsquo;ai indiqu\u00e9 pr\u00e9c\u00e9demment, enclenche un timer lorsqu&rsquo;il initialise une entr\u00e9e contenue dans un update. Chaque fois que cette entr\u00e9e est de nouveau annonc\u00e9e par un update, le timer est remis \u00e0 0. Si le timer n&rsquo;est pas raffraichi pendant 6 updates cons\u00e9cutifs (<em>3 minutes<\/em>), la destination est d\u00e9clar\u00e9e <strong>Possibly Down<\/strong> comme pr\u00e9c\u00e9demment.<\/p>\n<p style=\"padding-left: 30px;\">Toujours comme pr\u00e9c\u00e9demment, le routeur garde cette route dans l&rsquo;\u00e9tat <strong>Possibly Down<\/strong> pendant 2 minutes (<em>4 updates<\/em>) avant de la d\u00e9clarer r\u00e9ellement HS et de valider une \u00e9ventuelle route de secours.<\/p>\n<p style=\"padding-left: 30px;\">Dans notre r\u00e9seau exemple, si R1 passe hors tension ou rencontre un probl\u00e8me logiciel qui le rend inop\u00e9rant, le r\u00e9seau 10.0.0.0 n&rsquo;est plus annonc\u00e9 \u00e0 R2 et R3. Ceux-ci attendront donc 5 minutes (3 minutes + 2 minutes) avant de d\u00e9clarer le r\u00e9seau HS dans leurs tables. Mais ils informeront R4 du probl\u00e8me par un co\u00fbt de 16 sur la route 10.0.0.0 quand la destination sera pass\u00e9e en <strong>Possibly Down<\/strong> dans leurs tables, soit donc au bout de 3 minutes ! Dans le d\u00e9tail, supposons que R1 passe HS juste apr\u00e8s avoir \u00e9mis un update normal \u00e0 R2 et R3. Ce moment sera appel\u00e9 t0 :<\/p>\n<ul>\n<li>R2 et R3 ne re\u00e7oivent donc plus d&rsquo;updates de R1 ensuite.<\/li>\n<li>R2 et R3 d\u00e9clare 10.0.0.0 Possibly Down dans leur table de routage \u00e0 t0+3&prime; (<em>6 updates plus tard<\/em>) et enclenchent leurs <strong>hold-time timers<\/strong>.<\/li>\n<li>A t0+3&rsquo;30\u00a0\u00bb, R2 et R3 informe R4 que 10.0.0.0 est inaccessible en pla\u00e7ant un co\u00fbt de 16 dans l&rsquo;update \u00e0 destination de R4.<\/li>\n<li>R4 placent donc le r\u00e9seau 10.0.0.0 Possibly Down \u00e0 t0+3&rsquo;30\u00a0\u00bb (<em>\u00e0 r\u00e9ception de l&rsquo;update de R2 et R3<\/em>) dans sa table et enclenchent son hold-time timer.<\/li>\n<li>A t0+5&prime;, R2 et R3 n&rsquo;ayant pas re\u00e7u de nouvel update pour 10.0.0.0 suppriment la route de leurs tables de routage et ne l&rsquo;\u00e9mettent plus vers R4.<\/li>\n<li>R4 ne recevant plus d&rsquo;updates contenant 10.0.0.0 de la part de R2 et R3, supprime 10.0.0.0 de sa table \u00e0 t0+5&rsquo;30\u00a0\u00bb.<\/li>\n<\/ul>\n<p style=\"padding-left: 30px;\">Donc, comme pr\u00e9c\u00e9demment, si votre r\u00e9seau aligne 10 routeurs sur une route, il faudra au minimum 5&rsquo;+(10*30&Prime;) = 10 minutes pour r\u00e9aligner vos tables ! Encore une fois on peut dire que RIP n&rsquo;est pas un mod\u00e8le de rapidit\u00e9 !<\/p>\n<h3>Pourquoi ?<\/h3>\n<p style=\"padding-left: 30px;\">J&rsquo;en vois qui se grattent la t\u00eate ! 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 :<\/p>\n<ul>\n<li><strong>Pour ne pas mettre en p\u00e9ril la stabilit\u00e9 du r\u00e9seau<\/strong> ! Si chaque fois qu&rsquo;il y a une micro-coupure sur un support les routeurs entamaient une reconfiguration imm\u00e9diate du r\u00e9seau nous aurions des tables de routage qui joueraient au yo-yo !!<\/li>\n<li><strong>Pour laisser le temps aux routeurs voisins de bloquer leurs tables pour la destination indisponible<\/strong>. Car si on ne temporisait pas la reconfiguration on risquerait d&rsquo;obtenir des boucles de routage dans le r\u00e9seau, ce qui n&rsquo;est franchement pas bien !<\/li>\n<\/ul>\n<p style=\"padding-left: 30px;\">Croyez-moi sur parole, il vaut mieux prendre un peu de temps pour rien que de mettre l&rsquo;ensemble du r\u00e9seau par terre !!<\/p>\n<h2>RIP ! Tu ne me dis pas tout &#8230;<\/h2>\n<p>RIP v1 pose un petit probl\u00e8me que la v2 a heureusement r\u00e9solu ! <strong>RIP v1 ne transmet pas les masques des r\u00e9seaux qu&rsquo;il annonce dans ses updates<\/strong>. <em>Dis comme \u00e7a, cela para\u00eet anodin, mais croyez-moi \u00e7a ne l&rsquo;est pas<\/em> ! Explication &#8230;<\/p>\n<h3>Un cas qui marche &#8230;<\/h3>\n<p style=\"padding-left: 30px;\">Supposons que pour \u00e9conomiser des adresses r\u00e9seaux vous mettiez en place sur votre r\u00e9seau d&rsquo;entreprise un plan d&rsquo;adressage IP form\u00e9 de sous-r\u00e9seaux. Par exemple, comme dans 90% des cas, vous allez utiliser le r\u00e9seau 10.0.0.0 qui est non routable internet (RFC1918) pour d\u00e9finir votre plan d&rsquo;adressage (Pour ceux qui sont d\u00e9j\u00e0 largu\u00e9s, je vous invite \u00e0 revoir l\u2019Excellent <a href=\"http:\/\/www.gatoux.com\/index.php\/le-plan-dadressage\/\">Chapitre 7<\/a> du cours IP.)<\/p>\n<p style=\"padding-left: 30px;\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-295 alignleft\" src=\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/SUBNET1.gif\" alt=\"\" width=\"400\" height=\"80\" \/>Supposons que vous ayez d\u00e9fini le plan d&rsquo;adressage ci-contre.<\/p>\n<p style=\"padding-left: 30px;\">Vous remarquez que tous les r\u00e9seaux physiques sont associ\u00e9s \u00e0 la m\u00eame adresse de classe A : 10.0.0.0. Celle-ci est divis\u00e9e en sous-r\u00e9seau par le masque 255.255.0.0 qui lui est attribu\u00e9. Ainsi on a pu cr\u00e9er les sous-r\u00e9seau 10.1.0.0\/16 \u00e0 10.4.0.0\/16 chacun d&rsquo;eux \u00e9tant affect\u00e9 \u00e0 un r\u00e9seau physique.<\/p>\n<p style=\"padding-left: 30px;\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-296 alignleft\" src=\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/SUBNET2.gif\" alt=\"\" width=\"400\" height=\"142\" \/>La table de routage du routeur R1 est dans ce cas telle que ci-contre.<\/p>\n<p style=\"padding-left: 30px;\">Les sous-r\u00e9seaux 10.1.0.0 et 10.2.0.0 sont bien rout\u00e9s. R2 et R3 ont chacun \u00e9mis un update comportant l&rsquo;adresse 10.1.0.0 (pour R2) et 10.2.0.0 (pour R3) vers R1. Cet update ne comportait pas de masques des adresses r\u00e9seaux mais R1 ayant les pieds dans les sous-r\u00e9seaux 10.3.0.0\u00a0et 10.4.0.0 a appliqu\u00e9 le masque associ\u00e9 \u00e0 ces adresses. Les entr\u00e9es sont donc correctes.<\/p>\n<h3>Un cas qui ne marche pas &#8230;<\/h3>\n<p style=\"padding-left: 30px;\">Maintenant, supposons que vous ayez un plan d&rsquo;adressage un peu diff\u00e9rent. Supposons que vos liens d&rsquo;interconnexions utilisent une autre adresse r\u00e9seau que celles employ\u00e9es sur les LANs (croyez-moi, c&rsquo;est tr\u00e8s courant !).<\/p>\n<p style=\"padding-left: 30px;\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-297 alignleft\" src=\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/SUBNET3.gif\" alt=\"\" width=\"400\" height=\"154\" \/>Vous pourriez avoir l&rsquo;adressage ci-contre.<\/p>\n<p style=\"padding-left: 30px;\">Les liens d&rsquo;interconnexions utilisent les adresses 11.0.0.0 et 12.0.0.0 (<em>science-fiction, mais bref &#8230;<\/em>), par contre les deux LANs conservent l&rsquo;adressage en 10.1.0.0\/16 et 10.2.0.0\/16. Les updates \u00e9mis ne comportant pas les masques associ\u00e9s aux adresses r\u00e9seaux, R1 ne peut pas interpr\u00e9ter le nombre de bits d\u00e9finissant la partie r\u00e9seaux et sous-r\u00e9seaux dans l&rsquo;adresse. Tout ce qu&rsquo;il sait, c&rsquo;est qu&rsquo;un r\u00e9seau ayant la valeur 10 en premier octet est un r\u00e9seau de classe A. Et i lsait que les r\u00e9seaux de classe A utilise le premier octet comme octet r\u00e9seau. Il en d\u00e9duit que R2 donne acc\u00e8s au r\u00e9seau 10.0.0.0 avec un co\u00fbt de 1. Mais R3 lui envoie un update similaire ! Comme les deux updates ont le m\u00eame co\u00fbt, il fait un choix. Ici la route par R2 est pr\u00e9f\u00e9r\u00e9e \u00e0 celle par R3.<\/p>\n<p style=\"padding-left: 30px;\">Est ce grave ? OUI !! Depuis R1 ou R2 essayez donc d&rsquo;envoyer des donn\u00e9es vers une station sur 10.2.0.0\/16 et vous m&rsquo;en direz des nouvelles !<\/p>\n<h3>Un cas qui aurait pu marcher !<\/h3>\n<p style=\"padding-left: 30px;\">OK ! Donc le probl\u00e8me vient du fait que R1 n&rsquo;a pas les pieds dans le r\u00e9seau 10.0.0.0 ? Qu&rsquo;\u00e0 cela ne tienne ! Ajoutons lui un LAN dans le r\u00e9seau 10.0.0.0 comme ci-dessous :<\/p>\n<p style=\"padding-left: 30px;\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-298 alignleft\" src=\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/SUBNET4.gif\" alt=\"\" width=\"400\" height=\"194\" \/>On pourrait penser que cela suffirait, car maintenant R1 peut appliquer le masque qui est affect\u00e9 \u00e0 l&rsquo;adresse IP de son interface E0 (masque 16). Mais non ! C&rsquo;\u00e9tait trop simple ! Parce qu&rsquo;en v\u00e9rit\u00e9 R2 ne l&rsquo;informe pas dans son update d&rsquo;un sous-r\u00e9seau 10.1.0.0 mais d&rsquo;un r\u00e9seau 10.0.0.0. La m\u00eame chose pour R3 ! Pourquoi ? Parce que l&rsquo;update est \u00e9mis sur un num\u00e9ro de r\u00e9seau diff\u00e9rent du num\u00e9ro de r\u00e9seau annonc\u00e9. Autrement dit :<\/p>\n<ul>\n<li>si R1 \u00e9met un update pour 10.1.0.0 sur un r\u00e9seau 10.0.0.0 il envoie bien la valeur 10.1.0.0, partant du principe que le routeur distant pourra appliquer son masque sur l&rsquo;update puisqu&rsquo;il est \u00e9galement dans le r\u00e9seau 10.0.0.0.<\/li>\n<li>si R1 \u00e9met un update pour 10.1.0.0 sur un r\u00e9seau diff\u00e9rent (11.0.0.0 par exemple), il envoie la valeur 10.0.0.0 partant du principe que le routeur distant ne peut comprendre la partie sous-r\u00e9seau puisqu&rsquo;il n&rsquo;a pas les pieds dans le r\u00e9seau 10.0.0.0.<\/li>\n<\/ul>\n<p style=\"padding-left: 30px;\">Donc la table de routage de R1 fait un choix entre les deux annonces 10.0.0.0 de R2 et R3. Ici elle choisie une route par R2. Par contre R1 garde un route distincte pour 10.3.0.0 car le r\u00e9seau lui est directement accessible sur son interface E0. En bref, encore une fois le sous-r\u00e9seau 10.2.0.0 est inaccessible depuis R1 et R2.<\/p>\n<h3>Enfin &#8230; Un cas qui aurait pu ne pas marcher !<\/h3>\n<p style=\"padding-left: 30px;\">Dans l&rsquo;exemple suivant, il n&rsquo;y a pas de probl\u00e8me ! Le routage vers les sous-r\u00e9seaux 10.2.0.0 et 10.3.0.0 est correct, pourtant R1 n&rsquo;a pas les pieds dans le r\u00e9seau 10.0.0.0 !<\/p>\n<p style=\"padding-left: 30px;\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-299 alignleft\" src=\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/SUBNET5.gif\" alt=\"\" width=\"500\" height=\"189\" \/>Certes ! Mais tous les sous-r\u00e9seaux du r\u00e9seau 10.0.0.0 sont accessibles par un seule et m\u00eame interface de R1 (interface S1). Donc tous ce qui concerne le r\u00e9seau 10.0.0.0 en g\u00e9n\u00e9ral est \u00e9mis par R1 vers R3. Comme R3 a les pieds dans le r\u00e9seau 10.0.0.0 et contr\u00f4lent les sous-r\u00e9seaux 10.2.0.0 et 10.3.0.0 il sait assurer le routage \u00e9galement. Enfin le LAN de R2 est en dehors du r\u00e9seau 10.0.0.0 donc il n&rsquo;y a plus de probl\u00e8mes.<\/p>\n<h3>Bilan ?<\/h3>\n<p style=\"padding-left: 30px;\">Si vous utilisez RIP v1, m\u00e9fiance !! La fa\u00e7on la plus intelligente de d\u00e9finir son plan d&rsquo;adressage quand on utilise RIP v1 est le dernier cas ! Il permet de diminuer le nombre de routes dans les tables de routage en condensant (<em>on dit en agr\u00e9geant !<\/em>) automatiquement les d\u00e9finitions de sous-r\u00e9seau, sans nuire au routage. Les autres cas sont \u00e0 proscrire !<\/p>\n<p style=\"padding-left: 30px;\">Rassurez-vous, RIP v2 a lev\u00e9 ces limitations car il transmet dans ses updates les masques de sous-r\u00e9seaux. Cette fonction est devenue n\u00e9cessaire \u00e0 partir du moment o\u00f9 l&rsquo;on a commenc\u00e9 \u00e0 utiliser le <strong>VLMS<\/strong> (<strong>V<\/strong>ariable <strong>L<\/strong>ength <strong>M<\/strong>asque <strong>S<\/strong>ubnet) qui permet de d\u00e9finir pour un m\u00eame r\u00e9seau des longueurs de masques diff\u00e9rentes. Mais c&rsquo;est une autre histoire &#8230;<\/p>\n<h2 dir=\"ltr\">Conclusion<\/h2>\n<p dir=\"ltr\">Il appara\u00eet maintenant clairement que RIP a de s\u00e9rieuses limites. Impl\u00e9menter ce protocole sur de grands r\u00e9seaux n\u00e9cessite d&rsquo;y regarder \u00e0 deux fois ! La limite des 15 routeurs maximum sur une route, le d\u00e9lai de convergence long, l&rsquo;\u00e9mission des tables de routages compl\u00e8tes sur le r\u00e9seau toutes les 30 secondes et l&rsquo;impossibilit\u00e9 de router des sous-r\u00e9seaux en version 1, ne militent pas vraiment en sa faveur !<\/p>\n<p dir=\"ltr\">Mais relativisons &#8230; RIP a \u00e9t\u00e9 pendant longtemps le seul protocole de routage interne vraiment correctement impl\u00e9ment\u00e9 par les constructeurs de routeurs et garantissant surtout une bonne interop\u00e9rabilit\u00e9 entre les diff\u00e9rentes marques de routeurs. On le trouve encore dans beaucoup de r\u00e9seaux et on l&rsquo;impl\u00e9mente encore sur des r\u00e9seaux de petites envergures ou pour assurer des fonctions simples (pour les experts : <em>v\u00e9rification de la pr\u00e9sence d&rsquo;un routeur au bout d&rsquo;un tunnel IP ne proposant pas de keepalive, par exemple<\/em>). RIP n&rsquo;est pas mort, j&rsquo;en prendrai pour exemple le fait qu&rsquo;\u00e0 ma connaissance les serveurs UNIX ne reconnaissent que RIP comme protocole de routage ou que lorsqu&rsquo;on veut relayer des informations de routage entre deux routeurs de marques diff\u00e9rentes ont choisi RIP. Alors ne l&rsquo;enterrez pas tout de suite !<\/p>\n<p dir=\"ltr\">Mais aujourd&rsquo;hui, il y a <strong>plus rapide<\/strong>, <strong>plus beau<\/strong>, <strong>plus fort<\/strong>, <strong>plus top<\/strong> quoi ! Il y a <strong>OSPF<\/strong> ! Mais attention, c&rsquo;est r\u00e9serv\u00e9 aux grands, aux beaux r\u00e9seaux, sinon c&rsquo;est du gachis ! Dans le chapitre suivant, je vous propose donc une petite pr\u00e9sentation \u00ab\u00a0ligth\u00a0\u00bb d&rsquo;OSPF !<\/p>\n<h5 align=\"center\"><a href=\"http:\/\/www.gatoux.com\/index.php\/rip-protocole-simple\/\">Page Pr\u00e9c\u00e9dente<\/a> | <a href=\"http:\/\/www.gatoux.com\/index.php\/ospf-du-bel-ouvrage\/\">Page Suivante<\/a><\/h5>\n","protected":false},"excerpt":{"rendered":"<p>Ce chapitre va sans doute bousculer un peu le protocole. Vous risquez \u00e0 la fin de vous dire que je ne l&rsquo;aime pas, que finalement c&rsquo;est du bas de gamme tout juste bon \u00e0 rel\u00e9guer au mus\u00e9e &#8230; C&rsquo;est faux ! RIP est un tr\u00e8s bon protocole, il sera capable de couvrir encore de nombreux\u2026 <span class=\"read-more\"><a href=\"https:\/\/racine.gatoux.com\/lmdr\/index.php\/limites-de-rip\/\">Lire la suite &raquo;<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":38,"comment_status":"closed","ping_status":"closed","template":"page-templates\/full-width.php","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"class_list":["post-476","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/pages\/476","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/comments?post=476"}],"version-history":[{"count":9,"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/pages\/476\/revisions"}],"predecessor-version":[{"id":537,"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/pages\/476\/revisions\/537"}],"wp:attachment":[{"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/media?parent=476"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}