Bon, ça fait plusieurs fois qu’on me “tacle” un peu sur ce sujet et je suis a chaque fois surpris de l’étonnement des clients et partenaires quand je déballe l’ensemble des solutions de redondance dont on dispose, et surtout les avantages que l’on peut avoir par rapport aux autres constructeurs. Je ne sais pas pourquoi on a cette réputation et je doute qu’un simple post sur ce blog permettra de nous débarrasser de cette image mais bon, j’essaye… Au moins ca me permettra d’avoir un doc écrit qui servira à appuyer mes réponses!
Pour ceux qui ont pu assister à CiscoLive il y avait une session formidable sur le sujet faite par Patrice Bellagamba. Il a commencé par lister toutes les solutions existantes avant de faire un gros plan sur uniquement l’une d’entre elle (redondance avec mLACP – Multi-chassis Link Aggregation Control Protocol) pendant 1H30! Il a été un peu au delà en indiquant comment redonder de même des VPWS (L2VPN point-à-point) avec cette techno. Pour ceux qui ont un accès web sur le portail CiscoLive n’hésitez pas à rejouer cette sessions si vous l’avez manquée (référence: BRKRST-2008).
Commençons par rappeler le problème: comme on le sait tous mieux vaut éviter les boucles sur un domaine de niveau 2… Si on commence à étendre les réseaux de niveau 2 au dessus du WAN et qu’on créé de multiples points d’attachement entre les PE et les CE alors on créé justement ces boucles… Dans un domaine STP (Spanning-Tree Protocol) va nous aider à bloquer des ports pour supprimer ces boucles… Mais quand on est dans un environnement VPLS difficile de garder ce STP de bout en bout… Il faut trouver autre chose. Alors quelles sont les options que l’on propose?
- Clusterisation des PE – on a des solutions pour clusteriser des PE sur 2 châssis distants: VSS (Virtual Switching System) et maintenant nV (sur ASR9k). L’idée est simple: pour résoudre le problème de redondance des PE, faisant en sorte de n’en voir plus qu’un. On va créer un simple Etherchannel entre le CE et le PE virtuel, puisque les deux PE forment en fait un seul élément, en s’assurant qu’il y a un lien qui arrive sur chaque châssis physique. De part sa simplicité, c’est certainement la solution préférée dans l’entreprise (de nombreux système VSS sont installés) et on espère voir une large adoption côté SP avec l’ASR9k. Rappelons au passage que l’ASR9k commence à faire son apparition dans l’entreprise pour l’interconnexion de datacenters où VPLS est une option de transport répandue. Un autre avantage de cette solution est que les 2 liens CE-PE vont fonctionner en mode actif/actif.
- STP et mac address withdrawal – pour les lecteur les plus assidus j’avais déjà mentionné brièvement cette solution dans un récent post. L’idée est simple, on garde un STP (PVST ou MST) entre PE et CE du côté que l’on souhaite redonder et on va utiliser STP pour bloquer en permanence un des lienw CE-PE. Ce mécanisme est particulièrement adapté à un mode dans lequel CE et PE sont gérés par la même personne: en France pas de problème donc! C’est également parfait dans un design H-VPLS entre les U-PE et N-PE. Doc détaillée ICI. Pour le temps de convergence ça va par contre dépendre de la topologie STP dans sa globalité, quelques études s’imposent.
- REP à l’accès – REP (Resilient Ethernet Protocol) est un protocole basé sur le standard G.8032 qui permet d’éviter les boucles sur un niveau 2 (sans utiliser STP). Je reviendrai sur REP dans les prochaines semaines car ce protocole va débarquer en force sur nos réseaux d’entreprise alors qu’il était pour le moment cantonné à tout ce qui est Metro-Ethernet. REP permet d’assurer une convergence très rapide (50ms dans la plupart des cas, 200ms maximum). Dans certaines topologies adaptées on pourra utiliser REP pour éviter les boucles entre les PE et les CE avec une convergence très rapide et un côté déterministe qui plait bien.
- Utilisation de mLACP – mLACP est une extension de LACP (Link Aggregation Control Protocol) pour fonctionner quand les liens physiques se terminent sur différents châssis. mLACP se repose sur ICCP (Inter-Chassis Communication Protocol) pour permettant aux PE de se synchroniser au sein d’un Redundancy Group (RG). Vu du client il y aura un seul Etherchannel. mLACP va gérer l’Etherchannel pour éviter les boucles et garder le service up&running. Notons qu’on a la possibilité de fonctionner en mode actif/actif entre les 2 PE via une répartition des VLANs sur les liens d’attachement. Pour les plateformes: 7600 ou ASR9k. C’est la réponse à ceux qui ne veulent pas entendre parler de clusteriser à la VSS leur routeurs du fait de leur sensibilité au discours de séparation des control-plane pour assurer la meilleure disponibilité.
Notons que pour toutes ces solutions on a un gros point fort: on est réellement capables d’avoir une convergence très rapide sur tout le réseau. je m’explique: l’intérêt n’est pas uniquement de trouver des mécanismes pour éviter les boucles mais surtout de s’assurer que l’on converge rapidement quand la topologie change. On aimerait ne pas avoir à attendre que les entrées dans les tables MAC expirent pour que le service reprenne (plusieurs minutes seraient alors nécessaires). Sur détection d’incident, les PE envoient aux PE distants des messages LDP de type “MAC address withdrawal” ce qui permet de supprimer les entrées concernées des tables MAC, base pour la convergence sur l’ensemble du domaine étendu!
Alors, qui peut encore dire qu’on manque de solutions pour redonder un VPLS? Et encore je n’aborde pas ici les technologies qui permettent de répondre aux besoins de L2 étendu sans même utiliser VPLS, par exemple OTV (Overlay Transport Virtualization) et LISP (Locator Identifier Separation Protocol). Ici on a une approche disruptive qui séduit de nombreux clients qui ne veulent pas de MPLS.
Authors
1 commentaires