Lorsque vous installez un \u00e9quipement IP sur un LAN vous renseignez dans sa configuration au minimum 3 param\u00e8tres :<\/p>\n
–\u00a0son adresse IP<\/strong> sur le LAN Rappelons \u00e9galement (on ne sait jamais<\/em>) que le paquet IP va \u00eatre encapsul\u00e9 dans une trame de niveau 2 (souvent Ethernet !) pour \u00eatre \u00e9mis sur le LAN vers le routeur. Cette trame \u00e0 une adresse de destination (entre-autre !<\/em>), dite \u00ab adresse MAC \u00bb. La premi\u00e8re fois que l\u2019\u00e9quipement IP devra \u00e9mettre un paquet IP au routeur (gateway) il ne conna\u00eet que son adresse IP, pas son adresse MAC ! Il va donc proc\u00e9der \u00e0 une r\u00e9solution ARP (vous vous souvenez ??<\/em>) pour d\u00e9couvrir cette adresse. Il l\u2019a m\u00e9morise ensuite dans sa table ARP. Il peut donc maintenant envoyer son paquet IP au routeur.<\/p>\n Voil\u00e0 ! Les cervelles sont rafra\u00eechies maintenant ! N\u2019oubliez pas ce concept parce qu\u2019on y reviendra plus tard ! Et maintenant passons \u00e0 la suite \u2026<\/p>\n Quel que soit le type de raccordement du site au r\u00e9seau (LL, SDSL, IP\/ADSL, RNIS, etc \u2026) on retrouve une constante ! Le routeur est connect\u00e9 \u00e0 un organe d\u2019acc\u00e8s (PoP, NAS ou BAS) via une connexion de niveau 2 (PPP, HDLC, Frame Relay, ATM, etc \u2026). Je vous renvoie \u00e0 l\u2019excellent Cours OSI\u00a0<\/a> pour vous rafraichir la m\u00e9moire si n\u00e9cessaire !<\/p>\n Il existe donc un \u00e9change de niveau 2 entre le routeur et l\u2019\u00e9quipement d\u2019acc\u00e8s, le routeur place ses paquets IP dans la trame. Donc, si la liaison physique (LL, SDSL, RNIS, etc \u2026) est coup\u00e9e (rupture du parcours filaire, modem hors service) la connexion de niveau 2 est rompu et le routeur le sait ! Il peut donc engager une proc\u00e9dure de secours.<\/p>\n Ici \u00e7a se complique \u2026 Nous pouvons tr\u00e8s bien envisager le cas \u00ab\u00a0rare\u00a0\u00bb o\u00f9 le backbone de l\u2019op\u00e9rateur rencontre un probl\u00e8me. Les r\u00e9ponses varient en fonction de la nature du r\u00e9seau backbone. Nous devrons envisager plusieurs cas\u00a0:<\/p>\n – Le r\u00e9seau backbone est de niveau 2 (Frame Relay, LL, Ethernet, etc \u2026) Nous avons de la chance\u00a0! Avec Frame Relay il est extr\u00eamement simple pour le routeur distant de d\u00e9tecter s\u2019il y a un probl\u00e8me dans le backbone\u00a0!<\/p>\n En effet, comme l\u2019indique le sch\u00e9ma ci-dessous, la connexion de niveau 2 est \u00e9tablie de bout en bout \u00e0 travers le r\u00e9seau backbone. Il s\u2019agit d\u2019un CVP<\/strong> (C<\/strong>ircuit V<\/strong>irtuel P<\/strong>ermanent ou PVC<\/strong>\u00a0: P<\/strong>ermanent V<\/strong>irtual C<\/strong>ircuit for english spoken).<\/p>\n Dans la r\u00e9alit\u00e9 ce n\u2019est pas tout \u00e0 fait juste \u2026 Un CVP est une succession de plusieurs circuits mis bout \u00e0 bout \u00e0 travers le r\u00e9seau. Entre chaque \u00e9quipement relais (commutateur Frame Relay) un circuit est \u00e9tabli. Le commutateur transf\u00e8re les trames selon une table de commutation renseign\u00e9e manuellement.<\/p>\n Dans le sch\u00e9ma ci-dessus un CVP \u00ab\u00a0rouge\u00a0\u00bb est cr\u00e9\u00e9 entre le routeur A et le PoP A et un CVP \u00ab\u00a0vert\u00a0\u00bb entre le PoP A et le PoP B. Chaque CVP est identifi\u00e9 par un num\u00e9ro (inscrit sur la trame Frame Relay) appel\u00e9 DLCI<\/strong> (D<\/strong>ata L<\/strong>ink C<\/strong>ontrol I<\/strong>dentifier).<\/p>\n Dans la table de routage du routeur A, une entr\u00e9e indique que tout paquet \u00e0 destination de B doit \u00eatre plac\u00e9 dans une trame Frame Relay avec un DLCI 10 et \u00e9mis sur son interface de sortie S0 (par exemple). Je sais que vous avez lu avec attention le cours \u00ab\u00a0Routage IP<\/a> \u00bb, je ne vous rappellerai donc pas comment cette table a \u00e9t\u00e9 renseign\u00e9\u00a0!<\/p>\n A la cr\u00e9ation du r\u00e9seau, l\u2019op\u00e9rateur a construit dans le backbone les liens virtuels\u00a0! Il a donc indiqu\u00e9 au PoP A\u00a0:<\/p>\n – qu\u2019il existe une connexion virtuelle avec le Site A via un DLCI 10 sur son interface S0 (par exemple) L\u2019aboutement des deux CVP est donc r\u00e9alis\u00e9\u00a0! C\u2019est la m\u00eame chose cot\u00e9 PoP B et site B.<\/p>\n Maintenant supposons que le lien entre le PoP A et la PoP B passe hors service. La connexion de niveau 2 entre ces deux PoP va \u00eatre rompue. Mais les routeurs A ou B ne le sauront pas puisque leurs connexions \u00e0 leurs PoP respectifs seront toujours actives\u00a0!<\/p>\n FAUX<\/strong>\u00a0<\/span>! Frame Relay a l\u2019heureuse id\u00e9e d\u2019embarquer avec lui le protocole LMI<\/strong> (L<\/strong>ocal M<\/strong>anagement I<\/strong>nterface). Celui-ci va se charger d\u2019informer tous les \u00e9l\u00e9ments de la connexion (du CVP) de l\u2019indisponibilit\u00e9 du tron\u00e7on PoP A \u2013 PoP B. Ainsi les routeurs A et B recevront une information selon laquelle la connexion Frame Relay est hors service. Ils pourront donc engager d\u2019\u00e9ventuelles proc\u00e9dures de secours \u2026<\/p>\n Remarque<\/u><\/strong>\u00a0: A noter que LMI permet donc \u00e9galement au routeur A d\u2019\u00eatre inform\u00e9 si la liaison d\u2019acc\u00e8s au site B est HS. En effet, le tron\u00e7on Frame Relay PoP B \u2013 Site B \u00e9tant HS tous les \u00e9l\u00e9ments du CVP sont inform\u00e9s. Ceci est vraiment tr\u00e8s pratique \u2026 Vous allez comprendre pourquoi en \u00e9tudiant ci-apr\u00e8s la m\u00eame probl\u00e9matique pour un r\u00e9seau IP.<\/p>\n Dans le cas d\u2019un backbone IP (ou MPLS), c\u2019est un peu plus compliqu\u00e9 \u2026 Sur le sch\u00e9ma ci-dessous nous avons toujours nos deux sites connect\u00e9s au backbone, mais celui-ci n\u2019est plus compos\u00e9 de commutateur Frame Relay mais de routeurs IP.<\/p>\n Chaque routeur dispose d\u2019une table de routage indiquant le next-hop pour atteindre chaque r\u00e9seau IP des sites A et B avec un co\u00fbt de route correspondant ici au nombre de routeurs \u00e0 traverser pour atteindre la destination (je sais \u2026 c\u2019est du RIP\u00a0! Et du RIP sur un backbone c\u2019est \u00e0 mourir de rire\u00a0! Mais c\u2019est pour l\u2019exemple\u00a0! Silence\u00a0!<\/em>).<\/p>\n Vous remarquerez, que dans cet exemple, les routeurs A et B ont uniquement une route par d\u00e9faut vers le backbone (0.0.0.0 via 11.0.0.2 pour A par exemple). En effet, cel\u00e0 est tr\u00e8s courant chez les op\u00e9rateurs, car cela simplifie les configurations routeurs. En une seule ligne de routage vous indiquez toutes les directions. Comme ces sites n\u2019ont qu\u2019un seul point de sortie, ce type de routage est largement suffisant\u00a0! Bien s\u00fbr cette configuration n\u2019a\u00a0 pas \u00e9t\u00e9 renseign\u00e9e par RIP mais a \u00e9t\u00e9 initialis\u00e9e manuellement par l\u2019administrateur \u2026 Malheureusement, cela ne va pas faire nos choux gras comme vous allez le voir ci-apr\u00e8s.<\/p>\n Supposons, comme pour le r\u00e9seau Frame Relay (je dirai FR dor\u00e9navant \u2026), que la liaison PoP A \u2013 PoP B tombe HS<\/strong> (H<\/strong>ors S<\/strong>ervice). Que se passe-t-il\u00a0?<\/p>\n Le sch\u00e9ma ci-dessous pr\u00e9sente la reconfiguration des tables de routage provoqu\u00e9e par RIP. Je vous renvoi au cours \u00ab\u00a0Routage IP<\/a>\u00bb si vous ne comprenez pas cette reconfiguration.<\/p>\n C\u2019est super\u00a0! On remarque que les PoP ont reconfigur\u00e9 leurs tables de routage et qu\u2019ils utilisent la route secondaire via le PoP C. Les routes primaires (en rouge dans le sch\u00e9ma) affichent un co\u00fbt de 16, elles sont donc HS. Donc la rupture du lien PoP A \u2013 PoP B n\u2019a pas eu de cons\u00e9quence et les sites A et B peuvent continuer d\u2019\u00e9changer. C\u2019est quand m\u00eame mieux qu\u2019en FR non\u00a0?<\/p>\n Remarque<\/u><\/strong>\u00a0: Juste pour info \u2026 En Frame Relay on peut aussi impl\u00e9menter des solutions de re-routage backbone en cas d\u2019indisponibilit\u00e9 de segments de CVP. Mais cela se fait par description manuelle est c\u2019est assez lourd. On ne l\u2019impl\u00e9mente g\u00e9n\u00e9ralement que pour des sections \u00ab\u00a0critiques\u00a0\u00bb.<\/p>\n Nous sommes dans un p\u00e9riode de malchance \u2026 Dans le m\u00eame temps, le PoP C tombe HS\u00a0! Ci-dessous le r\u00e9sultat\u00a0!<\/p>\n Vous remarquez que le PoP A n\u2019a plus de route vers le site B (r\u00e9seau 16.0.0.0) et que le PoP B n\u2019a plus de route vers le site A. Cette fois c\u2019est s\u00fbr\u00a0! Le backbone est bien plant\u00e9\u00a0! Mais les routeurs des sites A et B le savent-ils\u00a0?<\/p>\n Non<\/strong>\u00a0! Leurs routes par d\u00e9faut vers leurs PoP respectifs sont toujours actives, car les connexions de niveau 2 vers ces PoP sont toujours fonctionnelles\u00a0! Pourtant si les routeurs envoient des paquets IP \u00e0 leurs PoP ils ne seront pas rout\u00e9s\u00a0!<\/p>\n Les routeurs A et B devraient donc enclencher une solution de secours, mais ils ne le font pas car ils ne sont pas inform\u00e9s du probl\u00e8me backbone\u00a0! Quelle est la solution\u00a0?<\/p>\n Il n\u2019y en a pas deux\u00a0! Il faut faire participer les routeurs au jeu RIP\u00a0! L\u2019utilisation de routes par d\u00e9faut statiques (saisies manuellement par l\u2019administrateur \u2026 pour ceux qui ronflent au fond\u00a0!<\/em>) est donc contre indiqu\u00e9e si vous souhaitez mettre en \u0153uvre ici une solution de secours.<\/p>\n Reprenons notre exemple en consid\u00e9rant cette fois que RIP est impl\u00e9ment\u00e9 sur les routeurs A et B.<\/p>\n Les routeurs A et B re\u00e7oivent des informations de routage en provenance du backbone et dressent leur table de routage en cons\u00e9quence.<\/p>\n Pr\u00e9cision<\/u><\/strong>\u00a0: Je rappelle que le choix de RIP comme protocole de routage backbone est une h\u00e9r\u00e9sie\u00a0! Je le choisi uniquement parce qu\u2019il est plus facile de comprendre le routage. Dans la r\u00e9alit\u00e9 on pr\u00e9f\u00e9rera au minimum OSPF voir IS-IS pour un routage backbone\u00a0!<\/p>\n Maintenant si le lien PoP A \u2013 PoP B ainsi que le PoP C sont HS, on obtient\u00a0:<\/p>\n Vous remarquez que cette fois les routeurs A et B re\u00e7oivent une annonce RIP leur indiquant l\u2019indisponibilit\u00e9 des routes vers 10.0.0.0 et 16.0.0.0. Ils peuvent donc modifier leurs tables de routage. Ils sont donc maintenant en mesure d\u2019activer une solution de secours \u2026<\/p>\n Nous venons d\u2019\u00e9tudier la mani\u00e8re dont le site A va pouvoir d\u00e9tecter que son raccordement au r\u00e9seau est HS ou que le backbone complet et HS. Mais dans certains cas (que nous verrons plus tard), il est parfois \u00e9galement utile que le site soit capable de d\u00e9tecter qu\u2019un site distant (son site central par exemple) est \u00e9galement HS. Pour notre cas, par exemple, il faudrait que le site A d\u00e9tecte si le site B est HS \u2026<\/p>\n Comme dans le cas pr\u00e9c\u00e9dent, tout d\u00e9pend de la nature du backbone \u2026<\/p>\n Nous avons vu pr\u00e9c\u00e9demment que le protocole LMI permettait d\u2019informer les \u00e9l\u00e9ments constitutifs d\u2019un CVP lorsqu\u2019un des segments de ce CVP \u00e9tait HS.<\/p>\n C\u2019est donc tr\u00e8s simple, comme l\u2019indique le sch\u00e9ma ci-dessous, nous allons utiliser cette fonctionnalit\u00e9 pour informer A que la liaison d\u2019acc\u00e8s B, ou son routeur sont HS.<\/p>\n Le site A est donc inform\u00e9 par LMI et peut enclencher son \u00e9ventuelle solution de secours\u00a0!<\/p>\n Comme pr\u00e9c\u00e9demment, il sera n\u00e9cessaire qu\u2019un protocole de routage dynamique soit mis en \u0153uvre pour informer le site A que le raccordement au site B est HS.<\/p>\n Le sch\u00e9ma suivant montre la reconfiguration des tables de routage RIP dans cette configuration.<\/p>\n Le PoP B d\u00e9tecte l\u2019indisponibilit\u00e9 du site B par une tomb\u00e9e du niveau 2 du raccordement. Il modifie sa table de routage et passe le r\u00e9seau 16.0.0.0 en \u00e9tat \u00ab\u00a0inaccessible<\/em>\u00a0\u00bb. Puis il informe par RIP le reste du r\u00e9seau. Les annonces RIP remontent jusqu\u2019au routeur du site A qui est ainsi inform\u00e9. Il peut donc engager une \u00e9ventuelle proc\u00e9dure de secours\u00a0!<\/p>\n Nous venons donc d\u2019\u00e9tudier les diff\u00e9rents cas d\u2019indisponibilit\u00e9s possibles ainsi que les m\u00e9thodes permettant aux routeurs de d\u00e9tecter ses d\u00e9fauts.<\/p>\n Nous avons vu \u00e9galement qu\u2019un backbone IP permettait d\u2019assurer une reconfiguration automatique permettant de le s\u00e9curiser. Ainsi il a fallu deux d\u00e9fauts simultan\u00e9s (dans notre exemple\u00a0!) pour le rendre inop\u00e9rant.<\/p>\n Chaque routeur de site a donc maintenant les moyens de savoir qu\u2019il doit passer en mode de secours. A la condition bien s\u00fbr qu\u2019une solution de secours ait \u00e9t\u00e9 pr\u00e9vu. Les chapitres suivants vont donc s\u2019attacher \u00e0 pr\u00e9senter les diff\u00e9rents solutions envisageables\u00a0!<\/p>\n <\/p>\n Une solution de secours doit bien s\u00fbr permettre \u00e0 un site de rester connecter \u00e0 son r\u00e9seau m\u00eame si son raccordement nominal est hors service. Le principe de base est donc extr\u00eamement simple ! Lorsque le routeur du site d\u00e9tecte que la connexion nominale vers le r\u00e9seau est Hors Service il bascule sur la solution\u2026 Lire la suite »<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":50,"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-594","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/pages\/594","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=594"}],"version-history":[{"count":6,"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/pages\/594\/revisions"}],"predecessor-version":[{"id":620,"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/pages\/594\/revisions\/620"}],"wp:attachment":[{"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/media?parent=594"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n–\u00a0son masque d\u2019adresse<\/strong>. Je rappelle que cela lui permet de savoir dans quel r\u00e9seau IP ou sous-r\u00e9seau il est plac\u00e9
\n–\u00a0l\u2019adresse IP de la Gateway<\/strong> de sortie du LAN (le routeur) \u00e0 qui il doit envoyer ses paquets si ceux-ci ne sont pas \u00e0 destination de son LAN IP local.<\/p>\nD\u00e9tection d\u2019indisponibilit\u00e9 du raccordement nominal<\/h2>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/05\/S6P4I2.jpg\")
Si le PoP de raccordement passe Hors Service (probl\u00e8me EDF ou site bombard\u00e9 par un op\u00e9rateur concurrent\u00a0!<\/em>) la connexion de niveau 2 est \u00e9galement hors service\u00a0!<\/p>\n<\/h2>\n
<\/h2>\n
D\u00e9tection d\u2019indisponibilit\u00e9 du backbone<\/h2>\n
\n– Le r\u00e9seau backbone est de niveau 3 (IP pur, MPLS)<\/p>\nBackbone Frame Relay<\/h3>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_CVP1.jpg\")
<\/p>\n
\n– qu\u2019il existe une connexion virtuelle avec le PoP B via un DLCI 20 sur son interface S1( par exemple)
\n– qu\u2019une commutation entre les trames DLCI 10 sur S0 et DLCI 20 sur S1 doit \u00eatre r\u00e9alis\u00e9e.<\/p>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_CVP2.jpg\")
<\/p>\nBackbone IP<\/h3>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_ROUTAGE1.jpg\")
<\/p>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_ROUTAGE2.jpg\")
<\/p>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_ROUTAGE3.jpg\")
<\/p>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_ROUTAGE4.jpg\")
<\/p>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_ROUTAGE5.jpg\")
<\/p>\nD\u00e9tection d\u2019indisponibilit\u00e9 d\u2019un site distant<\/h2>\n
Backbone Frame Relay<\/h3>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_LMI.jpg\")
<\/p>\nBackbone IP<\/h3>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_ROUTAGE6.jpg\")
<\/p>\nEn synth\u00e8se<\/h2>\n
Page pr\u00e9c\u00e9dente <\/a>| Page suivante<\/a><\/h5>\n","protected":false},"excerpt":{"rendered":"