Si le PoP de raccordement passe Hors Service (problème EDF ou site bombardé par un opérateur concurrent !) la connexion de niveau 2 est également hors service !
Détection d’indisponibilité du backbone
Ici ça se complique … Nous pouvons très bien envisager le cas « rare » où le backbone de l’opérateur rencontre un problème. Les réponses varient en fonction de la nature du réseau backbone. Nous devrons envisager plusieurs cas :
- Le réseau backbone est de niveau 2 (Frame Relay, LL, Ethernet, etc …)
- Le réseau backbone est de niveau 3 (IP pur, MPLS)
Backbone Frame Relay
Nous avons de la chance ! Avec Frame Relay il est extrêmement simple pour le routeur distant de détecter s’il y a un problème dans le backbone !
En effet, comme l’indique le schéma ci-dessous, la connexion de niveau 2 est établie de bout en bout à travers le réseau backbone. Il s’agit d’un CVP (Circuit Virtuel Permanent ou PVC : Permanent Virtual Circuit for english spoken).
Dans la réalité ce n’est pas tout à fait juste … Un CVP est une succession de plusieurs circuits mis bout à bout à travers le réseau. Entre chaque équipement relais (commutateur Frame Relay) un circuit est établi. Le commutateur transfère les trames selon une table de commutation renseignée manuellement.
Dans le schéma ci-dessus un CVP « rouge » est créé entre le routeur A et le PoP A et un CVP « vert » entre le PoP A et le PoP B. Chaque CVP est identifié par un numéro (inscrit sur la trame Frame Relay) appelé DLCI (Data Link Control Identifier).
Dans la table de routage du routeur A, une entrée indique que tout paquet à destination de B doit être placé dans une trame Frame Relay avec un DLCI 10 et émis sur son interface de sortie S0 (par exemple). Je sais que vous avez lu avec attention le cours « Routage IP Niv. 1 », je ne vous rappellerai donc pas comment cette table a été renseigné !
A la création du réseau, l’opérateur a construit dans le backbone les liens virtuels ! Il a donc indiqué au PoP A :
- qu’il existe une connexion virtuelle avec le Site A via un DLCI 10 sur son interface S0 (par exemple)
- qu’il existe une connexion virtuelle avec le PoP B via un DLCI 20 sur son interface S1( par exemple)
- qu’une commutation entre les trames DLCI 10 sur S0 et DLCI 20 sur S1 doit être réalisée.
L’aboutement des deux CVP est donc réalisé ! C’est la même chose coté PoP B et site B.
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 être rompue. Mais les routeurs A ou B ne le sauront pas puisque leurs connexions à leurs PoP respectifs seront toujours actives !
FAUX ! Frame Relay a l’heureuse idée d’embarquer avec lui le protocole LMI (Local Management Interface). Celui-ci va se charger d’informer tous les éléments de la connexion (du CVP) de l’indisponibilité du tronçon PoP A – 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’éventuelles procédures de secours …
Remarque : A noter que LMI permet donc également au routeur A d’être informé si la liaison d’accès au site B est HS. En effet, le tronçon Frame Relay PoP B – Site B étant HS tous les éléments du CVP sont informés. Ceci est vraiment très pratique … Vous allez comprendre pourquoi en étudiant ci-après la même problématique pour un réseau IP.
Backbone IP
Dans le cas d’un backbone IP (ou MPLS), c’est un peu plus compliqué … Sur le schéma ci-dessous nous avons toujours nos deux sites connectés au backbone, mais celui-ci n’est plus composé de commutateur Frame Relay mais de routeurs IP.
Chaque routeur dispose d’une table de routage indiquant le next-hop pour atteindre chaque réseau IP des sites A et B avec un coût de route correspondant ici au nombre de routeurs à traverser pour atteindre la destination (je sais … c’est du RIP ! Et du RIP sur un backbone c’est à mourir de rire ! Mais c’est pour l’exemple ! Silence !).
Vous remarquerez, que dans cet exemple, les routeurs A et B ont uniquement une route par défaut vers le backbone (0.0.0.0 via 11.0.0.2 pour A par exemple). En effet, celà est très courant chez les opérateurs, car cela simplifie les configurations routeurs. En une seule ligne de routage vous indiquez toutes les directions. Comme ces sites n’ont qu’un seul point de sortie, ce type de routage est largement suffisant ! Bien sûr cette configuration n’a pas été renseignée par RIP mais a été initialisée manuellement par l’administrateur … Malheureusement, cela ne va pas faire nos choux gras comme vous allez le voir ci-après.
Supposons, comme pour le réseau Frame Relay (je dirai FR dorénavant …), que la liaison PoP A – PoP B tombe HS (Hors Service). Que se passe-t-il ?
Le schéma ci-dessous présente la reconfiguration des tables de routage provoquée par RIP. Je vous renvoi au cours « Routage IP Niv. 1 » si vous ne comprenez pas cette reconfiguration.
C’est super ! On remarque que les PoP ont reconfiguré leurs tables de routage et qu’ils utilisent la route secondaire via le PoP C. Les routes primaires (en rouge dans le schéma) affichent un coût de 16, elles sont donc HS. Donc la rupture du lien PoP A – PoP B n’a pas eu de conséquence et les sites A et B peuvent continuer d’échanger. C’est quand même mieux qu’en FR non ?
Remarque : Juste pour info … En Frame Relay on peut aussi implémenter des solutions de reroutage backbone en cas d’indisponibilité de segments de CVP. Mais cela se fait par description manuelle est c’est assez lourd. On ne l’implémente généralement que pour des sections « critiques ».
Nous sommes dans un période de malchance … Dans le même temps, le PoP C tombe HS ! Ci-dessous le résultat !
Vous remarquez que le PoP A n’a plus de route vers le site B (réseau 16.0.0.0) et que le PoP B n’a plus de route vers le site A. Cette fois c’est sûr ! Le backbone est bien planté ! Mais les routeurs des sites A et B le savent-ils ?
Non ! Leurs routes par défaut vers leurs PoP respectifs sont toujours actives, car les connexions de niveau 2 vers ces PoP sont toujours fonctionnelles ! Pourtant si les routeurs envoient des paquets IP à leurs PoP ils ne seront pas routés !
Les routeurs A et B devraient donc enclencher une solution de secours, mais ils ne le font pas car ils ne sont pas informés du problème backbone ! Quelle est la solution ?
Il n’y en a pas deux ! Il faut faire participer les routeurs au jeu RIP ! L’utilisation de routes par défaut statiques (saisies manuellement par l’administrateur … pour ceux qui ronflent au fond !) est donc contre indiquée si vous souhaitez mettre en œuvre ici une solution de secours.
Reprenons notre exemple en considérant cette fois que RIP est implémenté sur les routeurs A et B.
