RSTP sur tunnel?


0

tl; dr: Est-il possible d'exécuter RSTP sur l2tp ou MPLS?

Nous avons loué une capacité de 1 Go au réseau d’un fournisseur de services, sur lequel nous avons envoyé un trafic multidiffusion udp. Le fournisseur nous laisse déposer à nos points de présence situés à différents endroits et nous terminons la liaison dans notre commutateur à chaque point de vente. Le fournisseur utilise une topologie en anneau et en cas de coupure de câble ou de problème similaire, le trafic sera acheminé sur l’autre chemin. Mais il y a des moments où il y a plusieurs coupes dans le ring et nous perdons complètement la connectivité.

Nous avons également une autre fibre noire louée auprès d’un autre fournisseur, qui n’est pas couverte par le premier fournisseur, mais atteint néanmoins les points de vente principaux et se termine par le même commutateur que le premier fournisseur.

Actuellement, si le réseau du premier fournisseur est en panne, nous basculons manuellement vers le second fournisseur. Évidemment, cela n’est pas optimal. Ce dont nous avons besoin, c’est que si la sonnerie du premier fournisseur échoue, le trafic passe automatiquement au deuxième fournisseur. Le défi est que le premier fournisseur exécute ses propres commutateurs et dispose d'une sorte de protocole de redondance en cours d'exécution pour la gestion des sonneries. Ils ne sont pas disposés à nous donner des informations sur la configuration de leur réseau ni à coopérer avec nous pour configurer RSTP.

Quelles options avons-nous dans ce scénario? J'imagine que nous courons un tunnel (l2tp / mpls)? entre nos commutateurs connectés au premier fournisseur et tout notre trafic passe par le tunnel et configure le protocole RSTP sur nos commutateurs. Est-ce que quelque chose comme ça est possible? Avons-nous une autre solution alternative?

Nous utilisons maintenant des interrupteurs bas de gamme au point de vue, et pouvons acheter le matériel nécessaire si nous avons une solution.

Réponses:


2

À moins que cela ne soit absolument nécessaire, ce dont je doute, exécuter la couche 2 sur un réseau étendu est une très mauvaise idée. STP nécessitera toutes sortes de réglages pour fonctionner correctement avec la latence accrue. Vous devez mesurer le temps de latence et l’appliquer à tous les calculs STP. Les diffusions, multidiffusions et monodiffusions inconnues devront parcourir de bout en bout chaque port de commutateur du domaine de couche 2, qui consomme une bande passante WAN coûteuse. La couche 3 contrôlera le trafic unicast de diffusion et inconnu, et PIM et IGMP veilleront à ce que la multidiffusion ne soit transmise qu'aux routeurs, commutateurs et ports de commutateur qui demandent le trafic de groupe de multidiffusion.

Vous pensez peut-être que le trafic de multidiffusion doit avoir la couche 2 au complet, mais ce n'est pas vraiment le cas. Vous pouvez utiliser le routage de couche 3 et de multidiffusion comme une situation beaucoup plus stable.

Presque rien aujourd'hui n'a besoin d'avoir une couche 2 de bout en bout; nous vivons dans un monde de couche 3. Le vieil adage de "Commute où tu peux, route où tu dois" a été complètement renversé. Il est maintenant même recommandé d’exécuter la couche 3 jusqu’au commutateur d’accès. Les commutateurs de couche 3 sont maintenant très avancés et moins coûteux qu’avant.

Vous devriez vraiment penser à utiliser des tunnels de couche 3 au lieu de tunnels de couche 2.


Je comprends cela, mais nous sommes coincés avec un fournisseur qui nous loue un lien L2.
Raj

@ Raj, oui, mais la couche 2 peut porter la couche 3. Chaque lien entre les routeurs est également un lien de couche 1 et de couche 2.
Ron Maupin
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.