planificateurs<\/strong> qui examinent, analysent, pr\u00e9voient, bref ! Qui doivent tout savoir avant de d\u00e9cider !<\/div>\n<\/li>\n<\/ul>\nLes premiers<\/strong> lorsqu’ils partent en vacances, c’est une aventure : On verra bien comment \u00e7a se passe ! Pour les seconds<\/strong>, c’est une gal\u00e8re, le parcours du combattant ! Il faut qu’ils sachent tout \u00e0 l’avance (o\u00f9 j’arrive, qui m’accueille quand je pars et comment, etc<\/em>). Personnellement, je suis plut\u00f4t dans le deuxi\u00e8me groupe (je sais … vous vous en fichez !<\/em>).<\/p>\nSupposons qu’un individu de chaque cat\u00e9gorie souhaitent se rendre \u00e0 Djibouti (pourquoi pas ?<\/em>) depuis Paris :<\/p>\n\n- le premier<\/strong> (l’aventurier<\/em>), trouve un panneau marqu\u00e9 \u00ab\u00a0Djibouti 3400 Km via Marseille\u00a0\u00bb (Si ! Si ! Il y en a un ! Place Vend\u00f4me \u00e0 Paris !<\/em>) et un autre marqu\u00e9 \u00ab\u00a0Djibouti 3500 Km via Le Caire\u00a0\u00bb (Si ! Si ! Ce second panneau est plant\u00e9 \u00e0 la Porte Maillot juste avant de prendre le p\u00e9riph\u00e9rique int\u00e9rieur !<\/em>). Que fait-il ? Je vous le donne en mille, ni une ni deux, il passe par Marseille. A Marseille il cherchera un panneau pour Djibouti (en esp\u00e9rant que ce ne soit pas via Paris !<\/em>).<\/li>\n
- le second<\/strong> (l’anxieux, le planificateur<\/em>), ne se contente pas d’une information si succincte ! D’accord, \u00ab\u00a03400 Km via Marseille\u00a0\u00bb et \u00ab\u00a03500 Km via Le Caire\u00a0\u00bb, mais comment je vais \u00e0 Marseille, je passe par o\u00f9 ? J’y vais en voiture, en avion, \u00e0 cheval, \u00e0 pied ? Je vais mettre combien de temps ? Et si l’avion est en panne, j’y vais comment ? Et puis, surtout, arriv\u00e9 \u00e0 Marseille ou au Caire, je prends quelle destination ? J’utilise quel moyen de transport ? Combien de temps je vais mettre ? etc … (Bileux, le type !<\/em>)<\/li>\n<\/ul>\n
Le premier<\/strong> se contente d’une information de proximit\u00e9 qui lui indique une direction et un co\u00fbt<\/strong>. Il va choisir la route via Marseille car son co\u00fbt est moindre (le nombre de kilom\u00e8tres<\/em>).<\/p>\nLe second demande un d\u00e9tail de la route \u00e0 suivre<\/strong>. Pour aller \u00e0 Marseille prendre le train \u00e0 Gare de Lyon, 70\u20ac de ticket, 450 Km, 3 heures. Puis prendre l’avion \u00e0 Marignane direction Djibouti, pas d’escales, 2950 Km, 1000\u20ac de billet, 5 heures de vol. Il existe \u00e9galement une possibilit\u00e9 de se rendre \u00e0 Djibouti par Le Caire, prendre l’avion \u00e0 Charles de Gaulle, escale \u00e0 Dubai, 3500 Km, 1200\u20ac de billet, 7 heures de vol. etc … Le second va calculer le co\u00fbt de la route lui-m\u00eame<\/strong> : 450 Km + 2950 Km = 3400 Km contre 3500 Km direct. Il passe aussi par Marseille car son crit\u00e8re de choix est \u00e9galement le nombre minimum de Km (je sais, il est finalement gu\u00e8re plus fut\u00e9 que le premier !<\/em>). Mais l’important est que son choix n’est pas bas\u00e9 que sur l’information du panneau de direction, il a d\u00e9taill\u00e9 la route<\/strong> est recalcul\u00e9 le co\u00fbt. Si la distance entre Marignane et Djibouti changeait (elle est bien bonne celle-l\u00e0 !<\/em>), il pourrait recalculer le co\u00fbt facilement.<\/p>\nToute la diff\u00e9rence est l\u00e0 ! Le premier fonctionne en \u00ab\u00a0vecteurs de distances<\/strong>\u00a0\u00bb alors que le second fonctionne en \u00ab\u00a0\u00e9tats de liens<\/strong>\u00a0\u00bb !<\/p>\nLe premier consid\u00e8re une route uniquement sur une indication de direction et de co\u00fbt \u00e9manant d’une information de proximit\u00e9<\/strong> (le panneau<\/em>). Le second consid\u00e8re une route sur une analyse de ses diff\u00e9rentes composantes<\/strong>. A l’inverse du premier, il a connaissance du d\u00e9tail de la route. Pour \u00eatre simpliste et abrupte on pourrait dire que le second r\u00e9fl\u00e9chi et pas le premier !<\/p>\nLa r\u00e9alit\u00e9 …<\/h2>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S3P6I2.gif\")
L’image pr\u00e9c\u00e9dente illustre bien la diff\u00e9rence fondamentale entre les deux approches en mati\u00e8re de construction des tables de routage. Transposons donc l’image \u00e0 la r\u00e9alit\u00e9.<\/p>\n
Prenons pour exemple la topologie r\u00e9elle du r\u00e9seau ci-contre et examinons comment chacun des deux types de protocoles va transcrire cette topologie dans une table de routage.<\/p>\n
<\/p>\n
<\/p>\n
Vecteurs de distance<\/h3>\n
Les protocoles de ce type ont un fonctionnement assez simple :<\/p>\n
\n- \n
\n- tous les routeurs du r\u00e9seau transmettent \u00e0 intervalles r\u00e9guliers<\/strong> (les Hello-Time<\/em>) des mises \u00e0 jours<\/strong> (des \u00ab\u00a0updates\u00a0\u00bb<\/em>) sur toutes leurs interfaces.<\/li>\n
- ces updates sont des paquets IP, \u00e9mis en broadcast<\/strong>, et contenant la totalit\u00e9 de leur table de routage<\/strong> (heu … presque ! Mais on verra \u00e7a plus tard !<\/em>).<\/li>\n
- tous les routeurs qui re\u00e7oivent ces updates en comparent le contenu avec les entr\u00e9es de leur table de routage<\/strong>. Ils consid\u00e9rent trois param\u00e8tres :\n
\n- la destination<\/strong> : si une destination appara\u00eet dans un update et qu’elle n’existe pas dans leur table, ils ajoutent l’entr\u00e9e \u00e0 leur table. L’entr\u00e9e sera constitu\u00e9e de l’adresse de destination indiqu\u00e9e, du co\u00fbt de route indiqu\u00e9, et de l’adresse du routeur qui a \u00e9mis l’update permettant d’ajouter l’entr\u00e9e. Cette adresse est en fait l’adresse IP source du paquet IP contenant l’update de r\u00e9f\u00e9rence.<\/li>\n
- le co\u00fbt<\/strong> : si une destination annonc\u00e9e dans un update existe dans la table de routage mais avec un co\u00fbt diff\u00e9rent, le routeur proc\u00e9de \u00e0 la mise \u00e0 jour du co\u00fbt.<\/li>\n
- l’adresse de l’\u00e9metteur<\/strong> : si une destination existe dans la table de routage mais a \u00e9t\u00e9 enregistr\u00e9e avec une adresse de next_hop (adresse de l’\u00e9metteur de l’update<\/em>) diff\u00e9rente de l’adresse \u00e9metteur de l’actuel update, le routeur compare les co\u00fbts. Si le co\u00fbt indiqu\u00e9 dans l’update est sup\u00e9rieur au co\u00fbt de l’entr\u00e9e existante, il ignore l’information. A l’inverse si le co\u00fbt indiqu\u00e9 dans l’update est inf\u00e9rieur, il remplace l’entr\u00e9e existante dans la table de routage par l’information de l’update.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/VECT_DIST.gif\")
L’algorithme est tr\u00e8s simple (Enfin ! J’ai quand m\u00eame n\u00e9glig\u00e9 quelques aspects que nous traiterons plus tard …<\/em>) ! Mais \u00e7a marche ! Nous \u00e9tudierons cela en d\u00e9tail avec RIP … Certes, il y a quand m\u00eame quelques \u00ab\u00a0loups dans le bois<\/em>\u00a0\u00bb !<\/p>\nAu final, le routeur se croit le centre du monde (du moins du r\u00e9seau<\/em>). Toutes les destinations sont des routes qui prennent des directions via des routeurs adjacents. Ce sont donc des vecteurs<\/strong>. Chaque route \u00e0 un co\u00fbt, c’est le poids du vecteur<\/strong>. Vous savez maintenant pourquoi on appelle cela un protocole \u00e0 vecteurs de distances ! Le concept est imag\u00e9 dans les deux sch\u00e9mas pr\u00e9sent\u00e9s. Le sch\u00e9ma du haut indique la topologie r\u00e9elle du r\u00e9seau, chaque routeur donne acc\u00e8s \u00e0 un r\u00e9seau IP (IP1 \u00e0 IP7). Le sch\u00e9ma de droite pr\u00e9sente la vue que le routeur contr\u00f4lant IP7 a du r\u00e9seau. Il a l’impression d’\u00eatre le centre du r\u00e9seau, les autres r\u00e9seaux IP lui apparaissent accessible via ses voisins (IP5, IP3 et IP4). Chaque r\u00e9seau de destination est un vecteur vers un voisin, d’une longueur variant avec le co\u00fbt de la route. Le vecteur IP1 est plus long que le vecteur IP6, son poids est plus important, car il faut faire 2 sauts pour atteindre IP1 contre un seul saut pour IP6.<\/p>\n\u00c9tats de liens<\/h3>\n
Lorsque nous \u00e9tudierons RIP nous verrons que les protocoles \u00e0 vecteurs de distance pr\u00e9sentent au moins deux inconv\u00e9nients majeurs :<\/p>\n
\n- \n
\n- \n
la charge r\u00e9seau induite par les updates<\/strong>. En effet, chaque routeur \u00e9met r\u00e9guli\u00e8rement sur le r\u00e9seau l’ensemble de sa table de routage. Ce trafic induit fini par ne pas \u00eatre n\u00e9gligeable, notamment dans le cas de grands r\u00e9seaux.<\/div>\n<\/li>\n- \n
mais surtout,
le protocole n’est pas tr\u00e8s r\u00e9actif<\/strong> (nous verrons pourquoi avec RIP !<\/em>). On parle de \u00ab\u00a0latence<\/strong>\u00a0\u00bb ou de \u00ab\u00a0d\u00e9lai de convergence<\/strong>\u00a0\u00bb longs.<\/div>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nIl a donc \u00e9t\u00e9 n\u00e9cessaire d’imaginer un autre type de fonctionnement. Nous ne l’\u00e9tudierons pas ici en d\u00e9tail, ce sera l’objet d’un cours sp\u00e9cifique. Le principe est le suivant :<\/p>\n
\n- \n
\n- \n
Chaque routeur transmet<\/strong>, comme pr\u00e9c\u00e9demment, des updates \u00e0 ses voisins<\/strong> (les routeurs voisins, pas les machines IP bien s\u00fbr !<\/em>).<\/div>\n<\/li>\n- \n
Ces mises \u00e0 jour sont plac\u00e9es
dans des paquets IP \u00e9mis en multicast<\/strong> (tiens ! \u00c7a change !<\/em>). Selon la nature des informations \u00e9mises l’adresse de multicast peut \u00eatre diff\u00e9rente, elle permet de s’adresser \u00e0 des routeurs ayant des r\u00f4les particuliers dans le r\u00e9seau. Ces updates indiquent non plus des destinations associ\u00e9es \u00e0 des co\u00fbts, mais des descriptions de liens<\/strong> (des link states<\/em>). Comme chaque lien est forc\u00e9ment associ\u00e9 \u00e0 une adresse IP r\u00e9seau il est identifi\u00e9 par cette adresse. Il est ensuite d\u00e9crit par sa nature (LAN, Point \u00e0 point, Multipoint<\/em>), son co\u00fbt d’acc\u00e8s (notion tr\u00e8s subjective, variant d’un protocole \u00e0 l’autre<\/em>), son \u00e9tat (actif, down, shut, etc<\/em>.), etc. Enfin le lien est \u00e9galement associ\u00e9 \u00e0 un identifiant de routeur qui lui donne acc\u00e8s (le routeur qui est branch\u00e9 sur le lien<\/em>).<\/div>\n<\/li>\n- \n
Ces informations sont stock\u00e9es dans une base de donn\u00e9es du routeur<\/strong>. Par un algorithme (de la mort !<\/em>), le routeur va d\u00e9terminer quelles suites successives de liens et de routeurs sont possibles pour atteindre une destination, c’est le calcul de routes<\/strong>. Si pour une m\u00eame destination il y a plusieurs routes possibles, il validera, dans sa table de routage, celle de co\u00fbt le plus faible. Le co\u00fbt d’une route correspond \u00e0 la somme des co\u00fbts des liens la composant<\/strong>.<\/div>\n<\/li>\n- \n
A\u00a0chaque update,
le routeur examinent les changements pour chaque lien par rapport aux pr\u00e9c\u00e9dentes mises \u00e0 jour<\/strong>. S’il n’y a pas de changement il ne recalcule pas les routes et n’\u00e9mets pas de mises \u00e0 jour \u00e0 ses voisins (c’est l\u00e0 que \u00e7a change !<\/em>). Par contre s’il y a un changement, il ne relaie vers ses voisins que l’information ayant chang\u00e9e<\/strong> (l\u00e0 aussi \u00e7a change ! Il n’envoie pas sa table de routage compl\u00e8te !<\/em>).<\/div>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nDonc les diff\u00e9rences fondamentales avec un protocole \u00e0 vecteurs de distances sont :<\/p>\n
\n- \n
\n- \n
les routeurs n’\u00e9mettent des updates que lorsque des liens changent d’\u00e9tats<\/strong> (co\u00fbts, indisponibilit\u00e9, etc<\/em>.)<\/div>\n<\/li>\n- \n
les updates \u00e9mis ne contiennent que des descriptions de liens<\/strong> ayant chang\u00e9 d’\u00e9tat, ils sont donc moins volumineux<\/div>\n<\/li>\n- \n
gr\u00e2ce aux updates d’\u00e9tats de liens,
les routeurs stockent dans leurs bases de donn\u00e9es une v\u00e9ritable carte topologique du r\u00e9seau<\/strong> et de son \u00e9tat<\/div>\n<\/li>\n- \n
les routeurs retransmettent imm\u00e9diatement les mises \u00e0 jour \u00e0 leurs voisins<\/strong>, ils compilent leur table de routage apr\u00e8s, le protocole est donc beaucoup plus r\u00e9actif !<\/div>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/ETAT_LIEN.gif\")
<\/p>\n
Malheureusement, il y au moins trois inconv\u00e9nients (il y a toujours des inconv\u00e9nients ! Rien n’est parfait en ce bas monde !<\/em>) \u00e0 l’utilisation de ce type de protocole :<\/p>\n\n- \n
\n- \n
il faut des routeurs poss\u00e9dant des performances CPU et des capacit\u00e9s m\u00e9moires sup\u00e9rieures<\/strong> \u00e0 celles n\u00e9cessaires pour les vecteurs de distance. C’est plus cher !<\/div>\n<\/li>\n- \n
ce type de protocole tr\u00e8s r\u00e9actif
n\u00e9cessite des r\u00e9glages pr\u00e9cis des timers de transmission<\/strong> car sa r\u00e9activit\u00e9 peut justement nuire \u00e0 la stabilit\u00e9 du routage (si on change toutes les tables pour une micro-coupure de liens, par exemple !).<\/div>\n<\/li>\n- \n
enfin, si un jour j’ai le courage de r\u00e9diger un cours sur OSPF, vous verrez que
ces protocoles sont assez complexes \u00e0 mettre en \u0153uvre<\/strong><\/div>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nQuels protocoles pour quelle famille ?<\/h2>\n
Les protocoles de routage se divisent donc en deux familles. J’ai d\u00e9lib\u00e9r\u00e9ment retir\u00e9 les protocoles de routage externe (EGP<\/strong> et BGP<\/strong>) qui ne peuvent \u00eatre class\u00e9s dans l’une ou dans l’autre famille. En effet, ils \u00e9tablissent des connexions avec d’autres routeurs et \u00e9changent des informations selon des m\u00e9canismes tr\u00e8s diff\u00e9rents. Pour BGP la notion de co\u00fbts est de plus tr\u00e8s complexe et n’a rien \u00e0 voir avec les co\u00fbts des IGP.<\/p>\nJ’ai \u00e9galement \u00e9limin\u00e9 les protocoles IS-IS<\/strong> et ES-IS<\/strong> car je ne les connais pas assez pour les classifier ! Si quelqu’un \u00e0 un avis \u00e9clair\u00e9 sur la question, je suis preneur !<\/p>\n\n\n\n| Protocole<\/th>\n | Description<\/th>\n<\/tr>\n |
\n| \n Les protocoles \u00e0 vecteurs de distances<\/strong><\/p>\n<\/td>\n<\/tr>\n\nRIP<\/strong><\/td>\nR<\/strong>outing I<\/strong>nformation P<\/strong>rotocol (version 1 & 2) : Le plus ancien, le plus simple mais encore tr\u00e8s utilis\u00e9 !<\/td>\n<\/tr>\n\nIGRP<\/strong><\/td>\nI<\/strong>nterior G<\/strong>ateway R<\/strong>outing P<\/strong>rotocol : Protocole propri\u00e9taire Cisco, mais comme Cisco est tr\u00e8s implant\u00e9 dans le monde du r\u00e9seau, on le trouve tr\u00e8s souvent.<\/td>\n<\/tr>\n\nE-IGRP<\/strong><\/td>\nE<\/strong>xtended IGRP <\/strong>: Apparut avec la version logicielle 11 de Cisco, il supplante peu \u00e0 peu l’IGRP. Il offre des fonctions plus \u00e9labor\u00e9es.<\/td>\n<\/tr>\n\nLes protocoles \u00e0 \u00e9tats de liens<\/strong><\/td>\n<\/tr>\n\nOSPF<\/strong><\/td>\nO<\/strong>pen S<\/strong>hortest P<\/strong>ath F<\/strong>irst : Un \u00ab\u00a0must\u00a0\u00bb, tr\u00e8s complet, tr\u00e8s performant, tr\u00e8s \u00e9labor\u00e9, mais tr\u00e8s compliqu\u00e9 et consommateur de ressources dans les routeurs. On le r\u00e9serve g\u00e9n\u00e9ralement \u00e0 de grands r\u00e9seaux.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nConclusion du chapitre<\/h2>\nJ’esp\u00e8re avoir \u00e9t\u00e9 suffisamment clair sur le concept. Si vous n’avez aucune connaissance du routage, il est probable que ce chapitre vous aura sembl\u00e9 un peu n\u00e9buleux, obscur, indigeste, etc. Rassurez-vous, apr\u00e8s une explication d\u00e9taill\u00e9e du fonctionnement de RIP vous comprendrez parfaitement le fonctionnement d’un protocole \u00e0 vecteurs de distances et aborderez donc plus facilement la diff\u00e9rence avec l’\u00e9tat de liens ! Donc rendez-vous au chapitre suivant : RIP<\/strong>.<\/p>\n | | | | | | | | | |
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/AVENTURIER.gif\")
\u00a0les aventuriers<\/strong> qui ne vivent que pour les sensations fortes et les surprises<\/div>\n<\/li>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/PLANIFICATEUR.gif\")
les planificateurs<\/strong> qui examinent, analysent, pr\u00e9voient, bref ! Qui doivent tout savoir avant de d\u00e9cider !<\/div>\n<\/li>\n<\/ul>\n