Le principe est simple\u00a0:<\/p>\n
* Le routeur de site est \u00e9quip\u00e9 d\u2019une carte RNIS et il est connect\u00e9 \u00e0 un acc\u00e8s RNIS
\n* Lorsque le lien nominal est hors service, il active une connexion RNIS en remplacement
\n* Lorsque le lien nominal revient \u00e0 l\u2019\u00e9tat UP (par opposition \u00e0 DOWN\u00a0! J\u2019aime d\u00e9velopper vos capacit\u00e9s linguistiques\u00a0!), il coupe la connexion RNIS et renvoi le trafic sur le lien nominal<\/p>\n
Il existe deux m\u00e9thodes principales\u00a0:<\/p>\n
* Le secours RNIS de bout en bout<\/strong> o\u00f9 le routeur du site A va appeler directement par RNIS le routeur du site B. Ceci implique donc que le routeur du site B soit \u00e9galement \u00e9quip\u00e9 d\u2019une carte RNIS\u00a0! C\u2019est le sujet de ce chapitre. On ne sait jamais\u00a0! Peut-\u00eatre que vous ne connaissez pas RNIS\u00a0! Je m\u2019en voudrais de vous laisser dans l\u2019expectative\u00a0!<\/p>\n RNIS<\/strong> = R<\/strong>\u00e9seau N<\/strong>um\u00e9rique \u00e0 I<\/strong>nt\u00e9gration de S<\/strong>ervice. En anglais on parle d\u2019ISDN<\/strong> (I<\/strong>ntegrated S<\/strong>ervice D<\/strong>ata N<\/strong>etwork). C\u2019est un r\u00e9seau d\u00e9velopp\u00e9 dans les ann\u00e9es 1990 amen\u00e9 \u00e0 remplacer le r\u00e9seau t\u00e9l\u00e9phonique analogique classique.<\/p>\n Dans la pratique il a compl\u00e8tement supplant\u00e9 le RTC<\/strong> (R<\/strong>\u00e9seau T<\/strong>\u00e9l\u00e9phonique C<\/strong>ommut\u00e9) classique aupr\u00e8s des entreprises, mais n\u2019a pas perc\u00e9 aupr\u00e8s des particuliers.<\/p>\n En dehors du fait qu\u2019il offre une num\u00e9risation des communications depuis le site client (contrairement \u00e0 l\u2019analogique qui n\u2019\u00e9tait \u00ab\u00a0num\u00e9ris\u00e9\u00a0\u00bb qu\u2019\u00e0 l\u2019arriv\u00e9e au central t\u00e9l\u00e9com), il offre de tr\u00e8s nombreux services.<\/p>\n Je n\u2019ai pas l\u2019intention de vous faire un cours sur RNIS, vous trouverez facilement sur le Web de quoi \u00e9tancher votre soif si n\u00e9cessaire. Ce qui nous importe ici c\u2019est\u00a0:<\/p>\n – sa structure en canaux B \u00e0 64 Kbps N\u2019oublions pas que ces acc\u00e8s rel\u00e8vent du monde t\u00e9l\u00e9phonique\u00a0! Un acc\u00e8s poss\u00e8de donc un num\u00e9ro (de t\u00e9l\u00e9phone) et il est n\u00e9cessaire de num\u00e9roter pour entrer en communication avec un correspondant.<\/p>\n Vous pouvez associer des s\u00e9quences de num\u00e9ros \u00e0 un m\u00eame acc\u00e8s. Ainsi vous pourriez donner 5 num\u00e9ros \u00e0 un T0\u00a0(01.46.46.10.00 \u00e0 05 par exemple). On appelle cela une SDA<\/strong> (S<\/strong>\u00e9lection D<\/strong>irecte \u00e0 l\u2019A<\/strong>rriv\u00e9e). Cette SDA peut ainsi \u00eatre r\u00e9partie entre 5 postes sur le bus S (derri\u00e8re la TNR<\/strong>\u00a0: T<\/strong>erminal N<\/strong>um\u00e9rique de R<\/strong>\u00e9seau).<\/p>\n Si vous souhaitez pouvoir \u00e9mettre 6 communications simultan\u00e9ment, vous pouvez commander plusieurs T0 (ici il vous en faut 3, car 3*2 canaux B = 6 canaux\u00a0!). Ces acc\u00e8s peuvent \u00eatre mont\u00e9s en groupement d\u2019acc\u00e8s<\/strong> et associ\u00e9s \u00e0 une seule s\u00e9quence SDA \u2026<\/p>\n Enfin au-del\u00e0 de 12 canaux (6 T0) il est pr\u00e9f\u00e9rable de commander un T2. Vous pouvez tr\u00e8s bien commander un T2 mais n\u2019y prendre que 15 canaux sur les 30. La facturation de l\u2019op\u00e9rateur s\u2019op\u00e8re au canal. A ce T2 vous pouvez bien s\u00fbr associer une s\u00e9quence SDA (50 num\u00e9ros par exemple). A noter qu\u2019un T2 sera g\u00e9n\u00e9ralement connect\u00e9 \u00e0 un \u00e9quipement capable de g\u00e9rer un grand nombre de lignes. Dans le cas d\u2019une utilisation pour le service t\u00e9l\u00e9phonique il sera connect\u00e9 \u00e0 un PABX<\/strong> (P<\/strong>rivate B<\/strong>ranch E<\/strong>xchange). Dans le cas d\u2019un r\u00e9seau informatique il pourra \u00eatre connect\u00e9 \u00e0 un NAS<\/strong> (N<\/strong>etwork A<\/strong>ccess S<\/strong>erver) ou un routeur. Nous y reviendrons \u2026<\/p>\n Pourquoi avoir plus de num\u00e9ros que de canaux possibles\u00a0? Parce que tout le monde ne t\u00e9l\u00e9phone pas en m\u00eame temps\u00a0! Vous pouvez tr\u00e8s bien avoir 30 personnes dans votre entreprise (donc 30 num\u00e9ros) mais ne jamais avoir plus de 10 communications en m\u00eame temps\u00a0!<\/p>\n Le sch\u00e9ma ci-apr\u00e8s tente de synth\u00e9tiser mes propos\u00a0!<\/p>\n Le cas 1<\/u> :<\/strong>\u00a0permet avec un acc\u00e8s de 2 canaux B (deux communications simultan\u00e9es) d\u2019adresser 5 postes t\u00e9l\u00e9phoniques gr\u00e2ce \u00e0 la SDA de 5 num\u00e9ros.<\/p>\n Le cas 2<\/u> :<\/strong> permet d\u2019obtenir un d\u00e9bit de support maximum de 128 Kbps en cumulant les deux canaux B. Une s\u00e9quence SDA est inutile puisqu\u2019il s\u2019agit de joindre uniquement un seul \u00e9quipement (le routeur). A noter que le routeur est install\u00e9 derri\u00e8re la TNR et devra pr\u00e9senter une interface S0 pour se connecter au Bus RNIS. Chez Cisco vous utiliserez des cartes WIC-1B-S\/T, WIC-2B-S\/T, NM-4B-S\/T ou NM-8B-S\/T selon le nombre d\u2019acc\u00e8s T0\/S0 \u00e0 connecter.<\/p>\n Le cas 3<\/u> :<\/strong>\u00a0permet de connecter un groupement de T0 (ici 3) \u00e0 un PABX. Ce PABX pourra desservir jusque 15 postes gr\u00e2ce \u00e0 la s\u00e9quence de SDA 15 num\u00e9ros associ\u00e9e. Bien s\u00fbr il ne pourra y avoir au maximum que 6 communications simultan\u00e9es.<\/p>\n Le cas 4<\/u> :<\/strong> pr\u00e9sente le raccordement d\u2019un PABX par un T2 offrant 30 canaux B. Il est associ\u00e9 \u00e0 une s\u00e9quence SDA de 100 num\u00e9ros et peut donc servir 100 postes. Mais seulement 30 communications simultan\u00e9es.<\/p>\n Le cas 5<\/u> :<\/strong> pr\u00e9sente un routeur connect\u00e9 \u00e0 un T2 offrant 30 canaux B. Le d\u00e9bit maximum possible sera donc de 1920 Kbps en cumulant tous les canaux B. Cet acc\u00e8s est uniquement associ\u00e9 \u00e0 un num\u00e9ro (dit T\u00eate de groupement<\/strong>) car il y a un seul \u00e9quipement \u00e0 adresser. Le routeur doit \u00eatre \u00e9quip\u00e9 d\u2019une interface T2. Chez Cisco vous utiliserez des interfaces NM-1A-E1 ou NM-1A-2E1 selon le nombre de T2 \u00e0 raccorder.<\/p>\n Le cas 6<\/u> :<\/strong> permet de connecter un groupement de T0 (ici 3) \u00e0 un routeur. Ce routeur disposera au maximum d\u2019un d\u00e9bit de 384 Kbps \u00e9gal \u00e0 6 fois 64 Kbps (6 canaux B). Cet acc\u00e8s est uniquement associ\u00e9 \u00e0 un num\u00e9ro (dit T\u00eate de groupement) car il y a un seul \u00e9quipement \u00e0 adresser.<\/p>\n Vous en savez maintenant suffisamment pour passer \u00e0 la suite \u2026<\/p>\n Comme indiqu\u00e9 pr\u00e9c\u00e9demment, cette m\u00e9thode permet de secourir \u00e0 la fois la liaison d\u2019acc\u00e8s au r\u00e9seau, le r\u00e9seau lui-m\u00eame et m\u00eame la liaison d\u2019acc\u00e8s au site de destination. Le routeur qui d\u00e9tecte l\u2019indisponibilit\u00e9 du parcours active la connexion RNIS vers son destinataire.<\/p>\n Les param\u00e8tres important dans cette configuration sont\u00a0:<\/p>\n – le d\u00e9bit du lien RNIS de secours Il va directement d\u00e9pendre du nombre de canaux B associ\u00e9 \u00e0 chaque acc\u00e8s. Dans notre exemple, si le site A dispose de 3 T0 (donc 6 canaux B) et que le site B dispose seulement d\u2019un T0, le d\u00e9bit maximum ne saurait exc\u00e9der 128 Kbps (2 * 64 Kbps). Ce d\u00e9bit est donc d\u00e9terminer \u00e0 la conception du r\u00e9seau en fonction de votre estimation du niveau de service acceptable en mode secours.<\/p>\n En effet, vous n\u2019\u00eates pas oblig\u00e9 de fournir en mode secours un d\u00e9bit identique au mode nominal. Par exemple, si vos deux raccordements r\u00e9seaux permettent un \u00e9change \u00e0 2 Mbps entre les deux sites, vous pouvez tr\u00e8s bien n\u2019autoriser que 1 Mbps en secours (soit donc 15 canaux B). On appelle cela\u00a0: la d\u00e9gradation de service<\/strong>\u00a0! Vous avez donc des secours en mode d\u00e9grad\u00e9s<\/strong> et d\u2019autres sans d\u00e9gradation (au m\u00eame d\u00e9bit que le d\u00e9bit nominal).<\/p>\n Ce choix de d\u00e9bit de secours va d\u00e9pendre\u00a0:<\/p>\n – de ce que peuvent supporter vos applications<\/strong> et vos utilisateurs (faites gaffe aux manifs\u00a0!)<\/em><\/p>\n – de ce que le DSI est pr\u00eat \u00e0 payer<\/strong>\u00a0! Forc\u00e9ment, un acc\u00e8s T2 (30 canaux B => 1920 Kbps) est plus cher qu\u2019un T0 (2 canaux B => 128 Kbps)\u00a0! En plus les cartes routeurs et les chassis routeurs ne seront pas n\u00e9cessairement les m\u00eames\u00a0! Un routeur supportant un T2 sera plus cher qu\u2019un routeur supportant un T0\u00a0!<\/p>\n – de ce que la technique vous autorise<\/strong> \u2026 Par exemple, en France vous ne pouvez pas d\u00e9passer 1920 Kbps pour une seule connexion RNIS de bout en bout\u00a0! En effet, le r\u00e9seau backbone RNIS n\u2019a pas \u00e9t\u00e9 con\u00e7u pour permettre des connexions \u00ab\u00a0haut d\u00e9bit\u00a0\u00bb d\u2019un bout \u00e0 l\u2019autre du r\u00e9seau. Il est pr\u00e9vu pour acheminer des connexions \u00e9parses (capillaires) r\u00e9parties entre diff\u00e9rents points du r\u00e9seau. En standard vous ne pouvez pas d\u00e9passer un d\u00e9bit de 1 Mbps en connexion bout en bout dans le r\u00e9seau\u00a0! Au-del\u00e0 vous devez faire une demande sp\u00e9cifique \u00e0 France T\u00e9l\u00e9com afin qu\u2019il v\u00e9rifie la capacit\u00e9 du backbone \u00e0 acheminer ce d\u00e9bit d\u2019un point \u00e0 un autre\u00a0! Ceci n\u2019emp\u00eache pas, en standard, un site d\u2019\u00e9tablir 5 communications simultan\u00e9es \u00e0 384 Kbps (soit 5 * 6 canaux B => 1920 Kbps) mais avec 5 sites distants diff\u00e9rents\u00a0pas avec un seul site\u00a0distant\u00a0! Donc si vos acc\u00e8s nominaux permettent un \u00e9change \u00e0 4 Mbps entre vos sites A et B, le secours RNIS vous limitera au mieux \u00e0 un d\u00e9bit de secours de 1920 Kbps\u00a0! Vous aurez donc un secours d\u00e9grad\u00e9 \u00e0 50%. Cette limitation pourra vous amenez \u00e0 choisir d\u2019autres types de secours que nous verrons dans les chapitres suivants \u2026<\/p>\n Bref\u00a0! Le choix du d\u00e9bit de secours est donc un d\u00e9licat et d\u00e9licieux compromis entre le supportable fonctionnel, le supportable financier et le possible technique\u00a0! Bon courage\u00a0!<\/p>\n Dans mes propos pr\u00e9c\u00e9dents j\u2019\u00e9voque constamment le cumul de canaux B pour obtenir un d\u00e9bit RNIS compris entre 128 Kbps (2\u00a0 canaux B) et 1920 Kbps (30 canaux B). Malheureusement, ne comptez pas sur RNIS pour vous livrer un UNIQUE train binaire au d\u00e9bit correspondant\u00a0! Si vous \u00e9tablissez une communication \u00e0 128 Kbps entre deux sites, vous aurez 2 connexions \u00e0 64 Kbps et non pas 1 connexion \u00e0 128 Kbps\u00a0!<\/p>\n Ce sera au routeur de mettre en \u0153uvre une technique permettant de cumuler le d\u00e9bit de ces deux canaux \u2026 Comme il ne peut pas le faire au niveau 1 puisque celui-ci est livr\u00e9 par les TNR comme deux circuits distincts, il va le faire au niveau 2\u00a0!<\/p>\n Le protocole de niveau 2 PPP <\/strong>(P<\/strong>oint to P<\/strong>oint P<\/strong>rotocol), permet d\u2019impl\u00e9menter une fonction dite de \u00ab\u00a0MultiLink<\/strong>\u00a0\u00bb. C’est-\u00e0-dire qu\u2019il va g\u00e9rer X connexions de niveau 2 comme une seule et m\u00eame connexion\u00a0! Les paquets niveau 3 transmis seront plac\u00e9s chacun dans des trames associ\u00e9es indiff\u00e9remment \u00e0 n\u2019importe quelle connexion de niveau 1 (canal B). Au final vous avez donc un d\u00e9bit de niveau 2 \u00e9quivalent \u00e0 X d\u00e9bit de niveau 1 (moins l\u2019overhead des encapsulations bien s\u00fbr\u00a0!).<\/p>\n La fragmentation et le s\u00e9quencement de paquets, comme sp\u00e9cifi\u00e9 dans le RFC 1717 (rendu obsol\u00e8te par le RFC 1990), scindent la charge de PPP et envoient des fragments sur des circuits parall\u00e8les. Dans ce\u00a0 cas pr\u00e9cis, ce \u00ab\u00a0faisceau\u00a0\u00bb de tubes Multilink PPP fonctionne comme une seule liaison logique, am\u00e9liorant le d\u00e9bit et r\u00e9duisant la latence entre routeur homologues.<\/p>\n Je n\u2019entrerai pas dans le d\u00e9tail du fonctionnement MultiLink (adressage du trunck, s\u00e9quencement trames et trunck, reprise sur erreur, etc \u2026), mais sachez que cette proc\u00e9dure est tout de m\u00eame assez consommatrice en ressource et n\u00e9cessite parfois d\u2019augmenter les performances des \u00e9quipements la mettant en \u0153uvre \u2026<\/p>\n Nous avons pr\u00e9c\u00e9demment \u00e9tudi\u00e9 le principe de d\u00e9tection d\u2019indisponibilit\u00e9 du lien ou du r\u00e9seau nous partons donc du principe que notre routeur de site A est inform\u00e9 de l\u2019indisponibilit\u00e9 du parcours (local ou distant). Il peut donc engager la proc\u00e9dure de bascule sur le lien de secours (ici le lien RNIS). Il est ici important de se pencher sur quatre aspects\u00a0:<\/p>\n – le type de secours (secours de lien \u00ab\u00a0physique\u00a0\u00bb ou secours par routage) Nous avons vu dans le chapitre \u00ab\u00a0D\u00e9tection d\u2019indisponibilit\u00e9\u00a0<\/a>\u00bb que le routeur du site A pouvait d\u00e9tecter trois types d\u2019indisponibilit\u00e9s\u00a0:<\/p>\n – l\u2019indisponibilit\u00e9 de sa liaison nominale de raccordement Dans le premier cas, on ne fera g\u00e9n\u00e9ralement pas appel \u00e0 un protocole de routage. Le routeur d\u00e9tectera localement la perte du niveau 2 (PPP ou HDLC) et informera sa table de routage que la destination est hors service.<\/p>\n Toutefois, nombre d\u2019\u00e9quipements (notamment chez Cisco) permettent de \u00ab\u00a0lier\u00a0\u00bb par programmation deux interfaces en d\u00e9finissant l\u2019une d\u2019elles comme secours de l\u2019autre. Chez Cisco la commande utilis\u00e9e est \u00ab\u00a0backup interface<\/strong> type num\u00e9ro<\/em>\u00a0\u00bb. Dans la programmation de l\u2019interface nominale (LL par exemple) vous d\u00e9finissez ainsi l\u2019interface de secours. Ce mode permet donc de basculer tr\u00e8s rapidement et sans protocole de routage sur l\u2019interface RNIS de secours. Nous sommes donc dans un mode que j\u2019appelle \u00ab\u00a0secours de lien physique\u00a0\u00bb.<\/p>\n Si les capacit\u00e9s de programmation de votre routeur ne vous permettent pas d\u2019impl\u00e9menter un \u00ab\u00a0secours physique\u00a0\u00bb, vous utiliserez le mode \u00ab\u00a0secours par routage\u00a0\u00bb pour suppl\u00e9er \u00e0 l\u2019indisponibilit\u00e9 d\u2019un lien de raccordement direct. En effet, l\u2019indisponibilit\u00e9 du lien de raccordement entra\u00eenera n\u00e9cessairement le passage \u00ab\u00a0down\u00a0\u00bb des routes associ\u00e9es dans la table de routage. Donc, si vous avez d\u00e9crit une route de secours dans cette table, elle sera activ\u00e9e …<\/p>\n Dans les cas d\u2019indisponibilit\u00e9 du backbone ou du site distant nous avons vu qu\u2019il nous fallait compter sur les updates d\u2019un protocole de routage pour nous informer du probl\u00e8me (sauf pour les r\u00e9seaux Frame Relay qui utilisent le protocole LMI). Le routeur du site A basculera donc sur le lien de secours sur commande de sa table de routage. Ceci implique que dans la table de routage il existe donc deux lignes de programmation pour une m\u00eame destination. Dans l\u2019exemple ci-dessous, sur le routeur A nous avons \u00a0:<\/p>\n – la route nominale<\/strong>\u00a0: 11.0.0.0 via 12.0.0.2 sur S1 => tout trafic externe \u00e0 envoyer au routeur 12.0.0.1 point d\u2019entr\u00e9e du backbone IP. Remarque\u00a0<\/u><\/strong>: vous noterez que l\u2019adresse r\u00e9seau 14.0.0.0 est affect\u00e9 \u00e0 l\u2019ensemble du r\u00e9seau RNIS ici. Chaque routeur qui serait connect\u00e9 \u00e0 ce r\u00e9seau aurait donc une adresse 14.x.x.x (ici A a l\u2019adresse 14.0.0.1 et B l\u2019adresse 14.0.0.2). En effet RNIS est un r\u00e9seau physique comme pourrait l\u2019\u00eatre un r\u00e9seau Frame Relay ou LL. Alors que sur le WAN IP, nous avons donn\u00e9 des adresses r\u00e9seaux diff\u00e9rentes pour chaque lien d\u2019entr\u00e9e, car nous sommes sur un\u00a0 r\u00e9seau de niveau 3.<\/p>\n Vous \u00eates toutefois des personnes avis\u00e9es\u00a0! Vous avez sans doute remarqu\u00e9 qu\u2019il y avait un petit probl\u00e8me\u00a0! Pour une m\u00eame destination deux routes sont d\u00e9crites dans la table de routage \u2026 Laquelle le routeur choisira-t-il\u00a0? S\u2019il choisi syst\u00e9matiquement la route RNIS, vous allez \u00e9coper d\u2019une belle facture en fin de mois\u00a0!<\/p>\n Il vous faudra donc impl\u00e9menter une notion de co\u00fbt<\/strong>\u00a0! Je vous renvoie \u00e0 l\u2019excellent cours \u00ab\u00a0Routage IP<\/a> \u00bb pour vous rafra\u00eechir la m\u00e9moire si n\u00e9cessaire. Vous donnerez donc un co\u00fbt sup\u00e9rieur \u00e0 la route via RNIS de mani\u00e8re \u00e0 \u00eatre certain que la route nominale sera choisie en priorit\u00e9 si elle est disponible. Dans le sch\u00e9ma pr\u00e9c\u00e9dent vous voyez que la route nominale a un co\u00fbt de 3 alors que la route RNIS a un co\u00fbt de 5.<\/p>\n Dans les deux derniers cas nous sommes donc dans ce que j\u2019appelle \u00ab\u00a0un secours par routage<\/strong>\u00a0\u00bb. A noter que ce mode est nettement moins r\u00e9actif que le premier car il faut attendre les d\u00e9clarations \u00ab\u00a0down<\/strong>\u00a0\u00bb des routes nominales ce qui selon les protocoles de routage peut prendre un certain temps. Rappelez-vous\u00a0 la notion de latence d\u00e9finie dans le toujours excellent cours \u00ab\u00a0Routage IP<\/a>\u00bb\u00a0!<\/p>\n Ces deux notions ne semblent \u00e0 priori pas avoir de rapport et pourtant c\u2019est le bien le cas\u00a0! N\u2019oublions pas que RNIS est un r\u00e9seau \u00e0 \u00e9tablissement de circuits de type t\u00e9l\u00e9phonique. Le co\u00fbt de revient de ce r\u00e9seau s\u2019\u00e9tablit sur 3 param\u00e8tres\u00a0:<\/p>\n – l\u2019abonnement d\u2019acc\u00e8s<\/strong> au r\u00e9seau factur\u00e9 forfaitairement en fonction du type d\u2019acc\u00e8s et du nombre de canaux souscrits Si on active une communication RNIS d\u00e8s que le routeur d\u00e9tecte une indisponibilit\u00e9 du parcours nominal et qu\u2019on la coupe seulement au r\u00e9tablissement de la liaison nominale, on peut \u00eatre confront\u00e9 \u00e0 une belle facture de communication au final (va pas \u00eatre content le DAF\u00a0!<\/em>).<\/p>\n On peut donc avoir une approche plus mesur\u00e9e\u00a0! On pourrait d\u00e9j\u00e0 n\u2019\u00e9tablir la communication que si le site doit \u00e9mettre des donn\u00e9es\u00a0! Apr\u00e8s tout si la coupure a lieu la nuit alors que personne ne travaille sur ce site ce n\u2019est peut-\u00eatre pas utile de jeter l\u2019argent par les fen\u00eatres \u2026 En plus on les conna\u00eet ces op\u00e9rateurs\u00a0! Pour les faire travailler la nuit sur le r\u00e9tablissement du lien nominal ce n\u2019est pas gagn\u00e9\u00a0! Au final on va activer et payer une communication pendant plusieurs heures pour rien\u00a0!<\/p>\n Mais \u00ab \u00c9mission de donn\u00e9es\u00a0\u00bb par le routeur, ne veut pas forc\u00e9ment dire \u00ab\u00a0Donn\u00e9es utiles\u00a0\u00bb\u00a0! Par exemple, si RIP est impl\u00e9ment\u00e9 sur votre routeur (parce qu\u2019en mode nominal il \u00e9change des updates avec d\u2019autres routeurs\u00a0(voir le cours \u00a0Routage Niv. 1). Votre routeur \u00e9met donc potentiellement des updates RIP sur toutes ses interfaces (donc l\u2019interface RNIS \u00e9galement) toutes les 30 secondes\u00a0! Est-ce vraiment utile\u00a0? Ne serait-il pas judicieux de s\u00e9lectionner uniquement le trafic en provenance du LAN (donc de machines \u00ab\u00a0utilisateur\u00a0\u00bb)\u00a0pour justifier de l\u2019activation du lien de secours\u00a0?<\/p>\n On peut aussi pousser le raisonnement plus loin \u2026 En mode nominal le routeur \u00e9change des donn\u00e9es avec l\u2019ensemble des sites du r\u00e9seau peut-\u00eatre qu\u2019en mode secours on peut se contenter de n\u2019\u00e9tablir la liaison de secours que lorsque du trafic doit \u00eatre \u00e9mis vers un seul site (site central par exemple) ou un nombre restreint de sites. Dans ce cas on peut ne s\u00e9lectionner que le trafic \u00e0 destination de certaines adresses IP destination.<\/p>\n En synth\u00e8se :<\/u><\/strong><\/p>\n – on temporise l\u2019activation de la connexion<\/strong> RNIS de secours jusqu\u2019\u00e0 ce que du trafic \u00e0 \u00e9mettre se pr\u00e9sente Tous les routeurs offrent des commandes\/fonctions de s\u00e9lection\/filtrage de trafic et temporisation d\u2019activation de connexion. Toutefois nous d\u00e9montrerons par la suite que dans les faits il n\u2019est pas si \u00e9vident de pouvoir limiter la connexion sur ces crit\u00e8res.<\/p>\n Cette consid\u00e9ration n\u2019est utile que dans un mode de secours \u00ab\u00a0bout en bout\u00a0\u00bb mettant en relation directement deux routeurs.<\/p>\n Nous avons d\u00e9montr\u00e9 pr\u00e9c\u00e9demment que les deux routeurs de notre r\u00e9seau \u00e9taient chacun en mesure de d\u00e9tecter l\u2019indisponibilit\u00e9 de leur parcours nominal. Dans ce cas, qui est responsable de l\u2019activation du lien de secours\u00a0? Si les deux d\u00e9cident simultan\u00e9ment d\u2019\u00e9tablir une communication de secours on sera confront\u00e9 \u00e0 un croisement des connexions (dans le meilleur des cas) ou (dans le pire des cas) \u00e0 non \u00e9tablissement de communication car l\u2019autre extr\u00e9mit\u00e9 est occup\u00e9 (en train de num\u00e9roter\u00a0!).<\/p>\n Dans l\u2019absolu il est donc n\u00e9cessaire d\u2019avoir un routeur responsable de l\u2019\u00e9tablissement de la communication (le ma\u00eetre) tandis que l\u2019autre ne fait que recevoir (l\u2019esclave). Ceci permet \u00e9galement de d\u00e9finir quel site paiera les co\u00fbts de communication (apr\u00e8s tout, le site isol\u00e9 appartient peut-\u00eatre \u00e0 une soci\u00e9t\u00e9 partenaire et non pas au titulaire du r\u00e9seau central\u00a0!). Dans la programmation d\u2019un routeur on peut donc d\u00e9finir qui est ma\u00eetre ou esclave.<\/p>\n Toutefois ceci n\u2019est pas totalement obligatoire car en RNIS les communications s\u2019\u00e9tablissent par une signalisation pr\u00e9alable sur Canal D (alors que la connexion de Data est \u00e9tablie sur Canal B). Donc il est possible \u00e0 deux routeurs (de la m\u00eame marque\u00a0! Largement conseill\u00e9\u00a0!) de s\u2019accorder sur qui \u00e9tablira la communication en cas de conflit d\u2019appel. Il est m\u00eame possible \u00e0 un routeur esclave de demander au routeur ma\u00eetre d\u2019\u00e9tablir une communication car l\u2019esclave a des donn\u00e9es \u00e0 lui \u00e9mettre\u00a0ou appelle ce mode le \u00ab\u00a0Call-back\u00a0\u00bb ! Vive le canal D\u00a0!<\/p>\n RNIS c\u2019est chouette\u00a0! Mais c\u2019est quand m\u00eame un r\u00e9seau public\u00a0! Si je connecte un de mes routeurs \u00e0 ce r\u00e9seau pour disposer d\u2019une solution de secours, qu\u2019est-ce qui me garanti qu\u2019il n\u2019y aura pas un petit malin (mal intentionn\u00e9\u00a0!<\/em>) qui ne cherchera pas \u00e0 \u00e9tablir une communication avec mon routeur pour s\u2019introduire dans mon r\u00e9seau\u00a0?<\/p>\n Heureusement les \u00e9quipementiers sont des gens avis\u00e9s\u00a0! Ils ont pr\u00e9vus deux niveaux de s\u00e9curit\u00e9 (au minimum)\u00a0:<\/p>\n – l\u2019identification du num\u00e9ro appelant<\/strong>\u00a0: lorsqu\u2019un routeur \u00e9tabli une communication (pas seulement un routeur d\u2019ailleurs\u00a0! N\u2019importe quel \u00e9quipement sur RNIS\u00a0!) le r\u00e9seau RNIS communique (via le canal D) le num\u00e9ro de l\u2019appelant (num\u00e9ro de t\u00e9l\u00e9phone\u00a0!). Il est donc possible d\u2019indiquer au routeur appel\u00e9 de n\u2019accepter les appels que depuis certains num\u00e9ros. C\u2019est d\u00e9j\u00e0 un bon niveau de s\u00e9curit\u00e9 car le num\u00e9ro appelant est fix\u00e9 par le r\u00e9seau op\u00e9rateur RNIS, il est donc difficile de le changer \u2026 Avec ces deux m\u00e9canismes nous sommes en mesure de garantir que la connexion \u00e0 nos routeurs via RNIS ne pourra pas se faire \u2026 facilement\u00a0! Mais rien n\u2019emp\u00eache d\u2019ajouter d\u2019autres m\u00e9canismes de s\u00e9curit\u00e9 au niveau applicatif (histoire d\u2019\u00eatre vraiment s\u00fbr\u00a0!<\/em>).<\/p>\n O\u00f9 en sommes-nous\u00a0?<\/u><\/strong><\/p>\n 1 \u2013 Mes routeurs ont d\u00e9tect\u00e9 l\u2019indisponibilit\u00e9<\/strong> du lien Les donn\u00e9es de niveau 3 (paquets IP) peuvent enfin \u00eatre achemin\u00e9es \u2026 L\u2019activation du secours est compl\u00e8te<\/strong>.<\/p>\n En se r\u00e9f\u00e9rant \u00e0 la description pr\u00e9c\u00e9dente on voit que l\u2019activation d\u2019un secours RNIS va prendre un certain temps, d\u2019autant plus long si on active un \u00ab\u00a0secours par routage\u00a0\u00bb. Pendant ce temps, il n\u2019y a plus de route disponible pour d\u00e9livrer les paquets qui se pr\u00e9sentent au routeur. Que se passe-t-il\u00a0?<\/p>\n Premi\u00e8re phase<\/strong>\u00a0: la route est hors service mais le routeur ne le sait pas encore (d\u00e9lai de transmission de l\u2019information, notamment en mode routage). Dans ce cas il transf\u00e8re les paquets sur l\u2019interface normale et ceux-ci sont perdus …<\/p>\n Deuxi\u00e8me phase<\/strong>\u00a0: le routeur sait que la route est indisponible mais n\u2019a pas encore de solution de secours active. Il buff\u00e9rise un peu les paquets et envoie \u00e0 l\u2019\u00e9metteur des paquets ICMP \u00ab\u00a0Destination unreachable\u00a0\u00bb. Charge \u00e0 l\u2019\u00e9metteur de calmer ses ardeurs s\u2019il a la bonne id\u00e9e d\u2019interpr\u00e9ter les messages ICMP. Toutefois, le routeur n\u2019a pas vocation \u00e0 buff\u00e9riser du trafic en attendant la disponibilit\u00e9 du lien de secours, ses buffers sont l\u00e0 pour temporiser un trafic notamment en cas de congestion mais pas pour stocker du trafic en attente de secours. Au final, les paquets re\u00e7us seront probablement perdus (\u00e9crasement buffer ou expiration du TTL => voir le cours IP<\/a>).<\/p>\n On voit donc que la bascule en mode secours engendrera in\u00e9vitablement une perte de paquets IP. Heureusement ces pertes seront d\u00e9tect\u00e9es par les couches sup\u00e9rieures (par exemple TCP), mais IP lui-m\u00eame n\u2019a aucun m\u00e9canisme pour s\u2019affranchir de ce probl\u00e8me. La couche TCP de l\u2019\u00e9metteur proc\u00e9dera donc \u00e0 une r\u00e9\u00e9mission des segments non re\u00e7us par le destinataire ce qui engendrera du point de vue de l\u2019utilisateur un ralentissement momentan\u00e9 tout \u00e0 fait perceptible.<\/p>\n Une activation rapide du secours est donc la bienvenue, mais nous devons \u00e9galement consid\u00e9rer les temporisations n\u00e9cessaires \u00e0 la mise \u00e0 jour des routages ou la stabilit\u00e9 du r\u00e9seau. Un choix difficile … On privil\u00e9giera les temporisations plut\u00f4t que d\u2019activer le secours d\u00e8s qu\u2019il y a une micro-coupure<\/strong> sur le lien nominal. Sans cela le rem\u00e8de pourrait \u00eatre pire que le mal en engendra des instabilit\u00e9s r\u00e9curentes des routes et des reconfigurations incessantes des tables de routage. De plus n\u2019oublions pas qu\u2019en principe nous sommes dans un mode \u00ab\u00a0exceptionnel\u00a0\u00bb. On active pas le secours tous les jours … Ou alors changez vite d\u2019op\u00e9rateur\u00a0!<\/p>\n Il y a deux grands cas de d\u00e9sactivation de la connexion RNIS de secours\u00a0:<\/p>\n 1 \u2013 Il n\u2019y a plus de trafic \u00e0 router sur cette liaison de secours. Nous avons vu pr\u00e9c\u00e9demment que pour \u00e9viter d\u2019\u00e9tablir la connexion de secours de mani\u00e8re prolong\u00e9e sans int\u00e9r\u00eat, nous placions des filtres de d\u00e9tection de trafic \u00ab\u00a0utile\u00a0\u00bb. Si le routeur ne re\u00e7oit plus ce type de trafic il pourra d\u00e9connecter la liaison RNIS pour \u00e9conomiser le co\u00fbt de communication.<\/p>\n Bien s\u00fbr il s\u2019agira de d\u00e9finir une temporisation d\u2019attente car il n\u2019est pas question de connecter \/ d\u00e9connecter le canal RNIS de mani\u00e8re incessante. Ceci g\u00e9n\u00e9rerai des instabilit\u00e9s dans le r\u00e9seau et un d\u00e9lai d\u2019acheminement du trafic difficilement supportable par l\u2019utilisateur (une connexion RNIS mettra au moins deux secondes \u00e0 s\u2019\u00e9tablir). Un bon d\u00e9lai de temporisation d\u2019attente serait d\u2019environ 5 minutes.<\/p>\n Dans la configuration \u00ab\u00a0secours physique de lien\u00a0\u00bb, le routeur va d\u00e9tecter le retour du lien nominal par la r\u00e9activation successive des niveau 1 puis 2 OSI. Lorsque la connexion niveau 2 est op\u00e9rationnelle, le routeur commande la d\u00e9connexion de l\u2019interface RNIS de secours associ\u00e9e (en mode backup interface) et place la route nominale en mode \u00ab\u00a0up\u00a0\u00bb dans la table de routage. G\u00e9n\u00e9ralement dans ce mode on associera \u00e9galement une temporisation de d\u00e9connexion car il ne s\u2019agirait pas de commander une d\u00e9connexion du lien RNIS pour un retour \u00e0 la normale fugitif du lien nominal.<\/p>\n Dans une configuration \u00ab\u00a0secours par routage\u00a0\u00bb, le routeur re\u00e7oit des informations de retour du parcours nominal \u00e0 la normale via des updates du protocole de routage. Ceci replace donc la route nominale \u00e0 l\u2019\u00e9tat \u00ab\u00a0up\u00a0\u00bb dans la table de routage. Comme cette route a un co\u00fbt plus int\u00e9ressant que la route de secours tout le trafic est de nouveau \u00e9mis sur le lien nominal. Ceci implique que l\u2019interface RNIS ne re\u00e7oit plus de trafic \u00e0 \u00e9mettre et donc se d\u00e9connectera comme indiqu\u00e9 dans le cas \u00ab\u00a0Plus de trafic \u00e0 router\u00a0\u00bb.<\/p>\n Vous noterez qu\u2019il existe un certain d\u00e9lai entre le moment o\u00f9 la route nominale est de nouveau en service et le moment o\u00f9 le routeur d\u00e9connecte la connexion RNIS de secours. Pendant ce temps le routeur dispose donc de deux possibilit\u00e9s pour acheminer le trafic. Ce n\u2019est pas vraiment un probl\u00e8me car IP ne se soucie pas du s\u00e9quencement des paquets. Le paquet X peut avoir \u00e9t\u00e9 achemin\u00e9 par le lien de secours, et le paquet X+1 par le lien nominal. Ce dernier \u00e9tant souvent d\u2019un rendement (d\u00e9bit, d\u00e9lai d\u2019acheminement) sup\u00e9rieur au lien de secours il est possible que P+1 arrive \u00e0 destination avant P, mais la station r\u00e9ceptrice r\u00e9ordonnera les paquets (voir le cours IP).<\/p>\n Par contre, si vous \u00eates en mode\u00a0 \u00ab\u00a0secours par routage\u00a0\u00bb il est vraiment important que les deux routes aient des co\u00fbts diff\u00e9rents favorisant le lien nominal. Sinon vous risquez d\u2019entrer dans un mode de partage de charge (le routeur \u00e9met un paquet sur un lien puis un autre sur l\u2019autre) qui g\u00e9n\u00e9rera du trafic sur le lien RNIS et emp\u00eachera sa d\u00e9connexion\u00a0!<\/p>\n A la sortie de ce chapitre tout \u00e0 l\u2019air pour le mieux. Nous avons r\u00e9ussi \u00e0 impl\u00e9menter une solution de secours permettant \u00e0 un site de s\u2019affranchir d\u2019un probl\u00e8me sur sa liaison de raccordement, sur le backbone ou sur le site distant. Le secours dit \u00ab\u00a0bout en bout\u00a0\u00bb semble donc optimum \u2026 Mais cherchons un peu plus loin\u00a0!<\/p>\n Un r\u00e9seau \u00ab\u00a0any to any\u00a0\u00bb sous entend que tous les sites d\u2019un r\u00e9seau peuvent (ou ont besoin \u2026 nuance non anodine\u00a0!<\/em>) \u00e9changer entre eux. Ceci s\u2019oppose \u00e0 un r\u00e9seau dit \u00ab\u00a0hub and spoke\u00a0\u00bb (ou \u00e9toil\u00e9 \u00ab\u00a0in french\u00a0\u00bb). Je vous renvoie au cours \u00ab\u00a0R\u00e9seaux mutualis\u00e9s\u00a0<\/a>\u00bb pour un petit raffraichissement sur les principales architectures de r\u00e9seau.<\/p>\n Dans notre cas supposons que notre site A active une connexion RNIS bout en bout avec un site central B. Par contre il a besoin d\u2019\u00e9changer des donn\u00e9es \u00e9galement avec un site C qui lui est connect\u00e9 \u00ab\u00a0normalement\u00a0\u00bb au r\u00e9seau (et donc acc\u00e8de \u00e0 B via le backbone). Comment va-t-il proc\u00e9der\u00a0?<\/p>\n La mauvaise solution serait d\u2019avoir pr\u00e9vu une double connexion RNIS de secours. Il vous suffit pour cela de d\u00e9crire 2 routes distinctes dans la table de routage du routeur. Une pour \u00e9tablir une connexion RNIS vers B et une vers C. Ces deux routes devront avoir des co\u00fbts inf\u00e9rieurs aux routes nominales respectives et devront chacune pointer vers une interface RNIS sp\u00e9cifique du routeur (Attention\u00a0: Concept tr\u00e8s variable selon les \u00e9quipementiers \u2026). C\u2019est donc techniquement tout \u00e0 fait r\u00e9alisable, mais c\u2019est un cauchemar en terme de dimensionnement, en terme de co\u00fbt et en terme d\u2019exploitation. Vous allez multiplier les interfaces RNIS sur votre routeur ce qui implique une augmentation du co\u00fbt du routeur, des abonnements RNIS et des consommations en cas d\u2019activation. Si pour contacter deux sites simultan\u00e9ment c\u2019est encore envisageable, le dimensionnement pour atteindre 10, 20 ou 50 sites risque d\u2019\u00eatre carr\u00e9ment cauchemardesque\u00a0! Quand \u00e0 l\u2019exploitation, je vous laisse imaginer la t\u00eate de votre table de routage (et de la programmation associ\u00e9e) pour r\u00e9aliser ce type de secours sur 50 sites \u2026<\/p>\n Il est donc plut\u00f4t pr\u00e9f\u00e9rable de pointer vers un seul site. On choisira g\u00e9n\u00e9ralement de laisser l\u2019initiative de l\u2019activation du secours au site distant (sous entendu site \u00ab\u00a0client\u00a0\u00bb d\u2019un site serveur) vers un site de rattachement central. Lorsque la connexion RNIS sera \u00e9tablie, ce site assurera le transfert des informations vers le site C via sa propre liaison nominale.<\/p>\n Nous venons d\u2019indiquer qu\u2019il est pr\u00e9f\u00e9rable que les sites distants \u00e9tablissent leur connexion RNIS de secours vers un site de rattachement, g\u00e9n\u00e9ralement le site central. C\u2019est exact \u2026 Mais ceci pose une question\u00a0: Combien de site distants peuvent potentiellement \u00e9tablir simultan\u00e9ment une connexion RNIS de secours\u00a0? Et accessoirement chacune de ces connexions est \u00e0 quel d\u00e9bit\u00a0?<\/p>\n En effet, supposons que nous ayons un r\u00e9seau de 50 sites distants \u00e9quip\u00e9s d\u2019un secours bout en bout vers un site central unique \u2026 Si chacun d\u2019eux \u00e9tabli une connexion \u00e0 64 Kbps en secours (d\u00e9bit ridicule de nos jours) le site central devra pouvoir recevoir 50 * 64 Kbps. Le routeur devrait donc \u00eatre \u00e9quip\u00e9 de 2 interfaces T2 (30 canaux par T2). C\u2019est cher \u00e7a\u00a0! Bon\u00a0! Ceux qui suivent vont me dire \u00ab\u00a0C\u2019est pour du secours\u00a0! Tous les sites distants ne vont pas \u00eatre Hors service en m\u00eame temps\u00a0!<\/em>\u00a0\u00bb. Et je vais r\u00e9pondre\u00a0\u00ab\u00a0Tout \u00e0 fait\u00a0! Bravo\u00a0! Mais vous oubliez que nous \u00e9tudions \u00e9galement le cas d\u2019activation du secours en cas d\u2019interruption backbone ou liaison distante, sous entendu liaison centrale\u00a0!\u00a0Ca vous interloque l\u00e0\u00a0?<\/em>\u00a0\u00bb.<\/p>\n Ceci implique une remarque importante<\/u><\/strong>\u00a0: La notion d\u2019activation de secours est une consid\u00e9ration locale. Ceci veut dire qu\u2019un site n\u2019activera un secours qu\u2019en cas d\u2019indisponibilit\u00e9 de son raccordement local, c’est-\u00e0-dire sa liaison de raccordement ou le PoP de raccordement au backbone. Le site ne prendra pas en consid\u00e9ration les cas d\u2019indisponibilit\u00e9 des sites distants ou du backbone. Le secours du backbone est de responsabilit\u00e9 op\u00e9rateur, le secours du site distant est de responsabilit\u00e9 \u2026 du site distant\u00a0! Sinon vous entrez dans des probl\u00e8matiques extr\u00eamement complexes. Cette remarque est vraie quelque soit les modes de secours que nous verrons ult\u00e9rieurement.<\/p>\n Ce probl\u00e8me \u00e9cart\u00e9, il reste toujours la question d\u2019\u00e9valuer le nombre de sites potentiellement en mode secours simultan\u00e9ment et le d\u00e9bit RNIS correspondant \u00e0 impl\u00e9menter cot\u00e9 site central. Ici il n\u2019y a pas de recette miracle\u00a0! Il faut avoir une double approche\u00a0:<\/p>\n 1 \u2013 Quel est le d\u00e9bit de secours distant maximum \u00e0 secourir\u00a0?<\/strong> En effet, sur 50 sites distants, vous pourriez tr\u00e8s bien avoir 40 sites \u00e0 64 Kbps et 10 sites \u00e0 512 Kbps. Ceci implique donc que votre site central devra d\u00e9j\u00e0 au minimum disposer d\u2019une connexion RNIS \u00e0 512 Kbps, ce qui lui permettra d\u2019assurer le secours d\u2019un site \u00e0 512 Kbps ou de 8 sites \u00e0 64 Kps.<\/p>\n 2 \u2013 Combien de sites peuvent simultan\u00e9ment passer en mode secours\u00a0?<\/strong> Ceci d\u00e9pendra beaucoup de la fiabilit\u00e9 de votre op\u00e9rateur\u00a0! Il n\u2019y a aucune approche statistique fiable\u00a0! Un peu d\u2019exp\u00e9rience me porte \u00e0 conseiller un taux maximum de 10% de connexions secours simultan\u00e9es. Toutefois il est pr\u00e9f\u00e9rable d\u2019avoir cette approche par grande classe de d\u00e9bit. Vous regroupez les sites de d\u00e9bit compris entre 64 et 256K, ceux compris entre 512K et 1M et enfin ceux au-del\u00e0. Apr\u00e8s cela vous prenez un peu de hauteur, de flair et vous adaptez\u00a0!<\/p>\n Au final si l\u2019on applique ces conseils \u00e0 notre configuration de 50 sites dont 40 secourus \u00e0 64 Kbps et 10 secourus \u00e0 512 Kbps on obtient\u00a0:<\/p>\n – D\u00e9bit de secours minimum\u00a0: 512 Kbps On voit que tout cela n\u2019est pas simple\u00a0! Si par malheur vous avez deux sites 512 Kbps qui passent en secours vous ne pourrez pas assurer leur secours simultan\u00e9\u00a0!<\/p>\n Je vous conseille donc de partir sur une option 16 canaux (1024 Kbps) permettant ainsi d\u2019assurer deux 512 Kbps ou un 512 Kbps + 8 sites 64 Kbps. C\u2019est ici que le flair s\u2019applique\u00a0!<\/p>\n Mais nous n\u2019en avons pas fini avec le dimensionnement du site central\u00a0! Tout \u00e0 l\u2019heure nous avons \u00e9voqu\u00e9 la possibilit\u00e9 offerte au site A de joindre le site C en passant par le lien nominal du site B, son site de rattachement de secours. Ceci implique donc que le lien nominal de B va v\u00e9hiculer du trafic A <=> C que normalement il ne supporte pas\u00a0! Ce lien a-t-il \u00e9t\u00e9 dimensionn\u00e9 pour cela\u00a0?<\/p>\n Dans l\u2019absolu on peut penser que ce n\u2019est pas trop grave, puisque par compensation ce lien n\u2019a plus \u00e0 supporter le trafic A <=> B initial (celui-ci passant maintenant par le lien RNIS de secours). Toutefois si en fait le site A discutait beaucoup avec le site C et peu avec le site B il est possible que le dimensionnement du lien nominal de B ait \u00e9t\u00e9 calcul\u00e9 avec un poids faible du trafic en provenance de A. Donc en assurant le transfert A <=> C il risque une surcharge. Ceci milite donc pour bien choisir le site de rattachement de secours. Il doit imp\u00e9rativement \u00eatre celui qui est en mode nominal le site central du trafic pour le site consid\u00e9r\u00e9. Le probl\u00e8me est que ceci n\u2019est pas forc\u00e9ment homog\u00e8ne au sein d\u2019un r\u00e9seau. On voit courrament des agences r\u00e9gionales discutant majoritairement avec leur Direction R\u00e9gionale et assez peu avec le si\u00e8ge central parisien (un peu de chauvinisme\u00a0!<\/em>). Par contre ces m\u00eames Directions R\u00e9gionales auront un trafic soutenu avec le si\u00e8ge. C\u2019est la notion de r\u00e9seau \u00ab\u00a0hi\u00e9rarchique\u00a0\u00bb d\u00e9velopp\u00e9e dans le cours \u00ab\u00a0R\u00e9seaux mutualis\u00e9s\u00a0<\/a>\u00bb. Il serait donc bienvenue d\u2019avoir un secours des agences vers leur direction de rattachement et un secours des directions vers le si\u00e8ge \u2026<\/p>\n Vous le voyez ce n\u2019est vraiment pas simple \u00e0 dimensionner\u00a0!<\/p>\n Lorsque vous les aurez c\u00f4toy\u00e9 un petit moment vous apprendrez une chose. Un DAF aime avoir une pr\u00e9dictibilit\u00e9 des co\u00fbts. Il budg\u00e9tise ! Il demande donc au DSI de lui indiquer le plus pr\u00e9cis\u00e9ment possible le co\u00fbt de revient de son r\u00e9seau (et d\u2019un tas d\u2019autres choses d\u2019ailleurs). Du coup le DSI devient comme le DAF\u00a0! Il veut un budget pr\u00e9dictible et contr\u00f4l\u00e9 pour son r\u00e9seau\u00a0! Le probl\u00e8me du secours RNIS c\u2019est qu\u2019une partie du co\u00fbt est fonction de l\u2019usage (le co\u00fbt de communication). En plus, ce co\u00fbt va varier en fonction de la distance\u00a0! Une communication Versailles \u2013 Paris n\u2019a pas le m\u00eame co\u00fbt minute qu\u2019une communication Marseille \u2013 Paris ou pire New-York \u2013 Paris\u00a0!<\/p>\n Quand la communication est locale et que de plus elle ne s\u2019\u00e9tablit que rarement parce que votre lien de raccordement est fiable, le co\u00fbt est n\u00e9gligeable. Par contre si vous \u00e9tablissez r\u00e9guli\u00e8rement des connexions de secours internationales ceci peut ne plus \u00eatre neutre\u00a0!<\/p>\n Avec le secours RNIS bout en bout il est malheureusement impossible de forfaitiser le co\u00fbt du secours sauf si vous arrivez \u00e0 n\u00e9gocier avec votre op\u00e9rateur la prise en charge de ces co\u00fbt de secours (apr\u00e8s tout c\u2019est de sa faute si le secours s\u2019active\u00a0!<\/em>).<\/p>\n Le secours RNIS bout en bout est aujourd\u2019hui d\u00e9suet pour les raisons \u00e9voqu\u00e9es pr\u00e9c\u00e9demment\u00a0:<\/p>\n Dans le chapitre suivant nous allons donc \u00e9tudier une \u00e9volution permettant de r\u00e9pondre \u00e0 la majorit\u00e9 de ces critiques. Il s\u2019agit du secours RNIS par NAS.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" C\u2019\u00e9tait, jusqu\u2019\u00e0 il y a peu, la m\u00e9thode la plus courante. Elle pr\u00e9sentait un bon \u00ab\u00a0rapport qualit\u00e9 \u2013 prix\u00a0\u00bb. Relativement peu on\u00e9reuse (du moins tant que le secours n\u2019est pas activ\u00e9), simple \u00e0 impl\u00e9menter et assez fiable. Elle est maintenant souvent remplac\u00e9e par le secours ADSL (du moins en France), nous y reviendrons. Remarque\u00a0:\u2026 Lire la suite »<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":51,"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-596","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/pages\/596","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=596"}],"version-history":[{"count":8,"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/pages\/596\/revisions"}],"predecessor-version":[{"id":627,"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/pages\/596\/revisions\/627"}],"wp:attachment":[{"href":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/wp-json\/wp\/v2\/media?parent=596"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n* Le secours RNIS par NAS<\/strong> o\u00f9 le routeur du site A va appeler un \u00e9quipement sp\u00e9cial du backbone. Celui-ci va \u00ab\u00a0abouter\u00a0\u00bb sa connexion RNIS au backbone et ainsi le site retrouve l\u2019acc\u00e8s au r\u00e9seau. Ce sera le sujet du chapitre suivant.<\/p>\nPetit rappel sur RNIS<\/h2>\n
\n– les typologies d\u2019acc\u00e8s T0 et T2
\nVous pouvez souscrire deux types d\u2019acc\u00e8s RNIS\u00a0:
\n– l’acc\u00e8s T0 <\/strong>propose deux canaux (circuits) de communication simultan\u00e9s \u00e0 un d\u00e9bit de 64 Kbps (appel\u00e9s canaux B) et un canal de signalisation \u00e0 16 Kbps (appel\u00e9 canal D). Si l\u2019on cumule le d\u00e9bit des deux canaux B on peut donc obtenir une connexion \u00e0 128 Kbps au maximum sur un acc\u00e8s T0.
\n– l’acc\u00e8s T2 propose 30 canaux B \u00e0 64 Kbps et un canal D \u00e0 64 Kbps pour la signalisation. En cumulant le d\u00e9bit des 30 canaux B vous pouvez donc (en th\u00e9orie) obtenir une connexion \u00e0 1920 Kbps.<\/p>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_RNIS1.jpg\")
<\/p>\nGrands principes<\/h2>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_RNIS2.jpg\")
<\/p>\n
\n– le principe d\u2019activation du secours
\n– le principe du retour \u00e0 la situation nominale<\/p>\nLe d\u00e9bit du lien RNIS<\/h2>\n
MultiLink PPP (dit MLPPP)<\/h2>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_MULTILINK.jpg\")
<\/p>\nL\u2019activation du secours<\/h2>\n
\n– la temporisation d\u2019activation et filtrage ou s\u00e9lection du trafic
\n– la notion de ma\u00eetre \u2013 esclave (ou call-back)
\n– la notion d\u2019identification<\/p>\nType de secours<\/h3>\n
\n– l\u2019indisponibilit\u00e9 du backbone de rattachement
\n– l\u2019indisponibilit\u00e9 d\u2019un site distant<\/p>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_BACKUP_INTERFACE.jpg\")
<\/p>\n
\n– la route de secours<\/strong>\u00a0: par exemple 11.0.0.0 via 14.0.0.2 sur BRI0 => tout trafic externe \u00e0 envoyer au routeur 14.0.0.2 accessible via la liaison RNIS connect\u00e9e \u00e0 l\u2019interface BRI0 (BRI<\/strong> = B<\/strong>asic R<\/strong>ate I<\/strong>nterface)<\/p>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_BACKUP_ROUTAGE.jpg\")
<\/p>\nTemporisation d\u2019activation et filtrage de trafic<\/h3>\n
\n– le co\u00fbt de la communication<\/strong> en fonction de sa dur\u00e9e<\/strong> (en secondes g\u00e9n\u00e9ralement)
\n– le co\u00fbt de la communication en fonction de sa distance<\/strong> (une communication internationale est plus ch\u00e8re qu\u2019un communication locale\u00a0!)<\/p>\n
\n– on s\u00e9lectionne (filtre) le type de trafic<\/strong> susceptible de g\u00e9n\u00e9rer la connexion RNIS<\/p>\nMa\u00eetre \u2013 esclave et Call-back<\/h3>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_CALL_BACK.jpg\")
<\/p>\nIdentification<\/h3>\n
\n– l\u2019authentification PAP\/CHAP<\/strong>\u00a0: En r\u00e9seau et plus g\u00e9n\u00e9ralement en informatique on est parano (souvent \u00e0 juste titre\u00a0!), donc plus on est \u00ab\u00a0secure\u00a0\u00bb mieux c\u2019est\u00a0! L\u2019identification de l\u2019appelant est donc renforc\u00e9e par une authentification protocolaire. PAP<\/strong>\/CHAP<\/strong> (P<\/strong>assword A<\/strong>uthentication P<\/strong>rotocol\u00a0:\u00a0Protocole d\u2019authentification de mot de passe \/ C<\/strong>hallenge H<\/strong>andshake A<\/strong>uthentication P<\/strong>rotocol : Protocole d\u2019authentification par tests) sont deux m\u00e9canismes du protocole PPP<\/strong> (proc\u00e9dure de niveau 2 qui se met en place sur la connexion de niveau 1 correspondant au canal B \u2026 Vive OSI\u00a0!) qui permet d\u2019authentifier les partenaires d\u2019une connexion PPP. Pour faire simple, ils permettent l\u2019\u00e9change d\u2019un mot de passe (qui aura \u00e9t\u00e9 configur\u00e9 dans chaque routeur) avant de valider la connexion. En PAP l\u2019\u00e9change est en clair (non crypt\u00e9) en CHAP l\u2019\u00e9change est crypt\u00e9 gr\u00e2ce \u00e0 un nombre al\u00e9atoire (le challenge\u00a0!) communiqu\u00e9 par l\u2019appel\u00e9 au moment de la demande de connexion.<\/p>\n
\n2 \u2013 Le routeur ma\u00eetre (d\u00e9fini suite \u00e0 ma programmation) a d\u00e9tect\u00e9 du trafic valide<\/strong> (correspondant \u00e0 mon filtrage) \u00e0 \u00e9mettre.
\n3 \u2013 Il a lanc\u00e9 une communication<\/strong> vers le routeur indiqu\u00e9 comme son correspondant de secours (programmation). S\u2019il est en mode call-back il a lanc\u00e9 une demande de rappel (call-back\u00a0: appel en retour) vers son routeur de secours.
\n4 \u2013 Le routeur appel\u00e9 a accept\u00e9 l\u2019appel RNIS<\/strong> (ou la demande de call-back) car il provient d\u2019un num\u00e9ro reconnu (programmation) transmis par le Canal D. Ils ont donc \u00e9tabli une communication de niveau 1 sur le(s) canal(aux) B.
\n5 \u2013 Ils ont ensuite v\u00e9rifi\u00e9 ensemble leurs identit\u00e9s<\/strong> via le protocole PAP\/CHAP du protocole PPP (via le Canal B) et ont conclut qu\u2019ils pouvaient valider la connexion PPP de niveau 2.<\/p>\nD\u00e9lai d\u2019activation et perte de trafic<\/h3>\n
D\u00e9sactivation du secours<\/h2>\n
\n2 \u2013 Le parcours nominal ayant n\u00e9cessit\u00e9 le passage en secours est revenu \u00e0 l\u2019\u00e9tat normal. On peut donc de nouveau envoyer les paquets sur le parcours normal.<\/p>\nPremier cas\u00a0: Plus de trafic \u00e0 router<\/h3>\n
Deuxi\u00e8me cas\u00a0: Le parcours nominal redevient op\u00e9rationnel<\/h3>\n
D\u00e9sactivation et double route<\/h3>\n
Les limites du secours RNIS bout en bout<\/h2>\n
Probl\u00e8me 1\u00a0: Les r\u00e9seaux \u00ab\u00a0any to any\u00a0\u00bb<\/h3>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_MULTI_BT_EN_BT.jpg\")
<\/p>\nProbl\u00e8me 2\u00a0: Le dimensionnement central<\/h3>\n
![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_DIMENSIONNEMENT_RNIS_CENTRAL.jpg\")
<\/p>\n
\n– D\u00e9bit de secours statistiques\u00a0: 10% de 40 (sites \u00e0 64 Kbps) + 10% de 10 (sites \u00e0 512 Kbps) = 4*64 Kbps + 1*512 Kbps
\n– Il vous faut donc un d\u00e9bit RNIS central \u00e9quivalent \u00e0 768 Kbps (256 + 512) soit 12 canaux B.
\n– Vous devrait donc choisir un acc\u00e8s de type T2 (jusque 30 canaux) avec un abonnement de 12 canaux ou un groupement de 6 acc\u00e8s T0 (financi\u00e8rement l\u2019option T2 devrait \u00eatre la meilleure). Il faut bien s\u00fbr que votre routeur central soit \u00e9quip\u00e9 des interfaces n\u00e9cessaires.<\/p>\n![\"\"](\"http:\/\/www.gatoux.com\/wp-content\/uploads\/2017\/04\/S6_DIMESIONNEMENT_ACCES_CENTRAL.jpg\")
<\/p>\nProbl\u00e8me 3\u00a0: Le co\u00fbt variable<\/h3>\n
En conclusion<\/h2>\n
\n
Page Pr\u00e9c\u00e9dente <\/a>| Page Suivante<\/a><\/h5>\n