Discussion :

[boboss123]

Bonjour,

Je cherche un protocole qui permette de gérer des boucles réseaux (pas du maillage comme STP) avec des temps de convergence de 20ms : Le protocole Ethernet Ring Protection Switching (ERPS) semble subvenir à ce besoin.
Mais est-ce qu'il n'y a pas d'autres protocoles plus efficace permettant de faire ça ? ... je cherche un protocole non propriétaire, répandu et simple à configurer/débuguer.

Est-ce que ERPS est basé sur le même principe que RSTP (envoie de BPDU toutes les 2 secondes où à chaque détection de changement de topologie) où est-ce qu'il flood du trafic toutes les 20ms pour détecter les problèmes ?

Merci d'avance,

PS : j'ai un doute, dans certaines fiches techniques c'est marqué 20ms et dans d'autres 50ms

[Invité]

Salut,

ERP, standardisé par l'ITU-T G.8032, utilise des messages R-APS (Ring Automatic Protection Switching) qui contiennent des champs dits OAM (Operations Administration Maintenance). Les R-APS sont l'équivalent des BPDU Spanning Tree dans une infra 802.1d/s/w, donc envoyés cycliquement (je crois que sur certaines plateformes Cisco, c'est configurable).

Lorsque tous les noeuds ERPS sont connectés, les messages R-APS échangés entre noeuds adjacents permettent aux noeuds de "casser" la boucle Ethernet.
Pour reprendre la terminologie du Spanning Tree, le lien qui est Blocking est appelé RPL (Ring Protection Link) et tous les autres (Forwarding) sont dans l'état Idle selon le fsm de ERPS.

Lorsqu'il y a changement de topologie (un lien Idle qui passe Down), les noeuds directement concernés bloquent les interfaces en question et émettent des messages de notification R-APS à tous les autres noeuds du ring. Le lien RPL est alors activé et tous les noeuds vident leurs caches (phase de FDB flushing) avant de repasser forwarding.

ERPS est dérivé de SNCP (Sub Network Connection Protection) et MS-SP-RING (Multiplex Section-Shared Protection Rings), les 2 protocoles de protection implémentés dans les boucles SDH/SONET et qui garantissent un ring recovery de 50 ms maximum.

Outre sa vitesse de convergence de l'ordre de 50 ms, le principal avantage de ERPS comparé à RSTP/MSTP, c'est qu'il ne dépend pas du "diamètre" (les valeurs par défaut des timers dans 802.1d/s/w sont basées sur un diamètre de 7 bridges/commutateurs et devraient en théorie être adaptés sur les très grosses archis L2).

Autre intérêt de ERPS, c'est que l'incident topologique est complètement localisé ce qui n'est pas forcément le cas dans un monde RSTP/MSTP très maillé. Inutile de dire que quand un opérateur déploie une boucle SDH de plusieurs kilomètres sur 30 noeuds SDH, il faut être certain d'envoyer les techniciens de maintenance au bon endroit

Steph

[boboss123]

Merci pour cette réponse complète

ERP, standardisé par l'ITU-T G.8032, utilise des messages R-APS (Ring Automatic Protection Switching) qui contiennent des champs dits OAM (Operations Administration Maintenance). Les R-APS sont l'équivalent des BPDU Spanning Tree dans une infra 802.1d/s/w, donc envoyés cycliquement (je crois que sur certaines plateformes Cisco, c'est configurable).

Ils servent à quoi exactement ces champs OAM ? Comme pour le RSTP, les R-APS d'un segment ne sont pas transmis sur les autres segments (chaque port génère ses propres R-APS ?) ?

Lorsqu'il y a changement de topologie (un lien Idle qui passe Down), les noeuds directement concernés bloquent les interfaces en question et émettent des messages de notification R-APS à tous les autres noeuds du ring. Le lien RPL est alors activé et tous les noeuds vident leurs caches (phase de FDB flushing) avant de repasser forwarding.

En RSTP lorsque d'un bridge détecte un problème, il envoie une indication de changement de topologie au bridge voisin qui lui transmet l'info à un autre voisin et ainsi de suite.
Si j'ai bien compris ce que tu viens d'écrire, ce n'est donc pas pareil en ERP : lorsqu'un nœud détecte un problème, il envoie l'info à tous les autres noeuds
=> c'est bien ça ?

ERPS est dérivé de SNCP (Sub Network Connection Protection) et MS-SP-RING (Multiplex Section-Shared Protection Rings), les 2 protocoles de protection implémentés dans les boucles SDH/SONET et qui garantissent un ring recovery de 50 ms maximum.

Alors pourquoi certains équipement annoncent 20ms ? Qu'est-ce qui les différencient des équipements 50ms ?
C'est 50ms à partir du moment où l'équipement à détecté la défaillance ou à partir du moment où la défaillance est réellement apparue ? Comment peut-on faire pour mesurer ce temps (et donc valider que l'équipement est conforme à la norme) ?

Outre sa vitesse de convergence de l'ordre de 50 ms, le principal avantage de ERPS comparé à RSTP/MSTP, c'est qu'il ne dépend pas du "diamètre" (les valeurs par défaut des timers dans 802.1d/s/w sont basées sur un diamètre de 7 bridges/commutateurs et devraient en théorie être adaptés sur les très grosses archis L2).

Sur un anneau géant, le temps de transmission des paquets ne peut pas être supérieur à 50ms ?

[Invité]

Ils servent à quoi exactement ces champs OAM ? Comme pour le RSTP, les R-APS d'un segment ne sont pas transmis sur les autres segments (chaque port génère ses propres R-APS ?) ?

Les champs permettent de différencier les divers types de messages R-APS (Forced Switch, Signal Failed, No Request, etc).
Les messages R-APS sont émis vers le multicast Ethernet 01-19-A7-00-00-01.
Lorsqu'on configure ERPS, on définit un VLAN de contrôle sur tous les noeuds. C'est dans ce VLAN que les multicasts R-APS sont diffusés.

Pour faire l'analogie avec MSTP, il est possible de monter plusieurs instances auxquelles on pourra associer la liste de VLAN voulue mais le traitement des multicasts restera confiné dans le control VLAN.

En RSTP lorsque d'un bridge détecte un problème, il envoie une indication de changement de topologie au bridge voisin qui lui transmet l'info à un autre voisin et ainsi de suite.
Si j'ai bien compris ce que tu viens d'écrire, ce n'est donc pas pareil en ERP : lorsqu'un nœud détecte un problème, il envoie l'info à tous les autres noeuds
=> c'est bien ça ?

En cas de cassure d'un lien entre 2 noeuds adjacents, ces derniers émettent un R-APS Signal Failed. Lorsque les noeuds du RPL reçoivent ce multicast, il déclenchent immédiatement une transition d'état de leurs ports de Protecting à Idle.

Alors pourquoi certains équipement annoncent 20ms ? Qu'est-ce qui les différencient des équipements 50ms ?
C'est 50ms à partir du moment où l'équipement à détecté la défaillance ou à partir du moment où la défaillance est réellement apparue ? Comment peut-on faire pour mesurer ce temps (et donc valider que l'équipement est conforme à la norme) ?

Certains équipementiers annoncent une vitesse de convergence inférieure à la "valeur historique" de 50 ms sur de "petits rings".
Ce qui n'est guère étonnant puisqu'en quelques années on a énormément gagné en temps de traversée des équipements.

Ce qu'il faut bien comprendre, c'est que dans ERPS, contrairement à n'importe quelle variante de Spanning Tree, il n'y a aucun calcul ni algorithme embarqué !
La convergence est immédiate puisque c'est l'administrateur Réseaux qui décide que le RPL, c'est ce lien entre le switch X et Y... Donc s'il y a incident topologique, c'est justement ce lien qu'il faudra réactiver, pas besoin de calcul... C'est à rapprocher des features Backbonefast et Uplinkfast de l'IOS Cisco, la transition d'états est immédiate !

Sur un anneau géant, le temps de transmission des paquets ne peut pas être supérieur à 50ms ?

La limite théorique du nombre de noeuds dans un ring ERPS est 255... Effectivement, pour un tel ring, la convergence pourra parfois dépasser les 50 ms, tout dépendra du nombre de noeuds ERPS entre le lien qui a cassé et le RPL.

Comme expliqué plus haut, la vitesse de convergence est quasiment la durée de transit du message R-APS depuis les noeuds défaillants vers le RPL puisqu'il n'y a aucun calcul.

Pour montrer la conformité des équipements à ERPS, il suffirait donc de :
- mesurer le temps de transit d'une trame Ethernet entre les noeuds ERPS "diamétralement opposés",
- vérifier que la durée de convergence suite à un incident est quasiment identique à ce temps de transit.

Steph

[boboss123]

Merci pour tes réponses, c'est toujours très instructif de discuter avec toi

Donc si j'ai bien compris lorsque l'on veut mettre un réseau de type ring en place, on fait :
1- Installation/raccordement des équipements
2- Création des VLAN
3- Désactivation d'un des ports de la boucle pour qu'il n'y ait plus de boucle
4- Désactivation du spanning Tree
5- Configuration de ERP
6- Activation du port précédemment désactivés
C'est bien ça ?

Si le spanning tree et ERP sont activés en même temps, il se passe quoi ?