Discussion :

[gao.t]

Bonjour à tous,

J'ai dans l'idée de connecter plusieurs équipements industriel les uns aux autres (daisy-chain) en Ethernet. J'ai dans l'idée d'utiliser ce type de circuit intégré KSZ8873.
Puis, pour rendre le réseau un peu plus disponible, fermer la boucle avec un équipement qui pourrait gérer la redondance et éviter une tempête de diffusion. Par exemple un switch exécutant le protocole RSTP (Rapid Spanning Tree Protol).

J'ai cru comprendre que pour réaliser un anneau industriel disponible, le protocole à retenir est HSR. Mais les circuits intégrés ou équipement sérieux qui gèrent ça sont assez chers (Flexibilis/ ou Hirschmann par exemple).

Maintenant, les questions :
- quelqu'un a-t-il déjà mis en œuvre le type de solution décrite ? Si oui, quel est votre retour ?
- les puces de chez Micrel (racheté par Microchip), comme le KSZ8873 sont réputées difficiles à mettre en œuvre. Est-ce que vous partagez cet avis ?
- j'ai constaté que Micrel proposait un circuit intégré pas très cher qui supporte HSR ici. Quelqu'un l'a-t-il implanté et pourrait me faire un retour ?
- concernant les temps de cicatrisation du réseau, RSTP propose quelque chose de raisonnable. Mais je m'interroge plutôt sur le temps de latence qu'introduit la répétition des trames sur le switch qui supporte RSTP, dans le cas d'un problème réseau qui ouvre l'anneau. Quel impact sur les performances ?

Merci d'avance pour vos réponses.

[Invité]

- concernant les temps de cicatrisation du réseau, RSTP propose quelque chose de raisonnable. Mais je m'interroge plutôt sur le temps de latence qu'introduit la répétition des trames sur le switch qui supporte RSTP, dans le cas d'un problème réseau qui ouvre l'anneau. Quel impact sur les performances ?

Dans ce type de topologie minimaliste d'un point de vue Spanning Tree (mono-bridge RSTP), la transition d'état sera:
1) de l'ordre de 1 à 2 ms si le changement de topologie est un link failure sur le switch RSTP,
2) théoriquement 3 fois le Hello Time configuré sur le switch si c'est un link failure dans la daisy-chain.

A noter que dans ce type de design, je recommanderais de baisser le STP Hello Timer à 2 voire 1 secondes sur le switch RSTP pour accélérer la convergence... Dans le cas 2, et pour être certain de fixer les bonnes attentes, tu n'atteindras bien sûr jamais la vitesse de reconvergence d'un réseau régi par PRP/IEC62439, ce sera le scenario le plus pessimiste...

-VX

[gao.t]

Merci pour la réponse. Le temps de recouvrement demandé n'est pas critique, car d'un point de vue fonctionnel, j'ai un protocole de communication applicatif qui me permet de mettre temporairement le système dans un état sûr.

Mon problème est plutôt le temps de latence introduit par le commutateur qui supporte RSTP. Je ne sais pas comment est implémenté le protocole RSTP : y a-t-il un traitement réalisé pour transférer la trame sur le commutateur RSTP ou bien ce dernier active-t-il la répétition sur détection de perte d'un lien dans la daisy-chain, le commutateur se comportant alors comme un commutateur "classique" (un ASIC qui répète rapidement le signal sur l'autre port) ? J'espère être clair.

[Invité]

Mon problème est plutôt le temps de latence introduit par le commutateur qui supporte RSTP. Je ne sais pas comment est implémenté le protocole RSTP : y a-t-il un traitement réalisé pour transférer la trame sur le commutateur RSTP ou bien ce dernier active-t-il la répétition sur détection de perte d'un lien dans la daisy-chain, le commutateur se comportant alors comme un commutateur "classique" (un ASIC qui répète rapidement le signal sur l'autre port) ? J'espère être clair.

Voici ce que sera l'état nominal de cette infra :



Le switch aura une interface Ethernet en mode Blocking.
L'interface Forwarding envoie des BPDU Spanning Tree.
A noter que l'interface Blocking n'émet pas de BPDU, en revanche, elle continue à les écouter...

Supposons qu'il y ait coupure dans la daisy-chain entre deux KSZ8873 :



L'interface Blocking ne recevant plus de BPDU, elle va subir une transition d'état Blocking -> Forwarding et commencera à émetttre des BPDU.
Alors effectivement lorsque le KSZ8873 "isolé" (celui qui est à gauche) va devoir envoyer du trafic à l'un des KSZ8873 de droite, les trames seront forwardées par le switch. Mais à ce stade, RSTP n'intervient plus dans le packet processing du switch... RSTP relève du Control Plane, pas du Forwarding Plane...

Le temps de latence que tu recherches est une donnée parfaitement définie (et généralement fournie) par l'équipementier, c'est ce qu'on appelle le temps de traversée. Il dépend aussi de la longueur de la trame...

Par exemple, sur un Cisco 3850, le temps de traversée d'une trame de longueur 1kB d'un port à un autre est de l'ordre de 5,5/6 microsecondes et je pense que les autres switches du marché doivent offrir des perfs équivalentes.

J'espère que ça répond à ta question...

-VX

[gao.t]

Mais à ce stade, RSTP n'intervient plus dans le packet processing du switch... RSTP relève du Control Plane, pas du Forwarding Plane...

C'était exactement ma question, merci. Je redoutais qu'il y ait du traitement en plus du forwarding.

Maintenant reste la question de savoir si cette approche est une bonne idée. Je ne sais pas si les KSZ8873 sont des IC exotiques, difficiles à mettre en œuvre ou s'il est plus prudent de faire du HSR en payant 40 euros la puce qui gère ça (sans être convaincu de la facilité à mettre en œuvre cette solution aussi).
As-tu déjà rencontré l'architecture que je décris (et que tu as si bien illustré) ? Est-ce une approche "bricolage" ou quelque chose de fréquent ?

[Invité]

C'était exactement ma question, merci. Je redoutais qu'il y ait du traitement en plus du forwarding.

Maintenant reste la question de savoir si cette approche est une bonne idée. Je ne sais pas si les KSZ8873 sont des IC exotiques, difficiles à mettre en œuvre ou s'il est plus prudent de faire du HSR en payant 40 euros la puce qui gère ça (sans être convaincu de la facilité à mettre en œuvre cette solution aussi).
As-tu déjà rencontré l'architecture que je décris (et que tu as si bien illustré) ? Est-ce une approche "bricolage" ou quelque chose de fréquent ?

Quelques remarques...

1) Je pense que cette topologie en apparence très simple peut poser des problèmes avec certains switches du marché, on est clairement dans un "corner case". Parce qu'en effet, puisqu'aucun équipement de la daisy-chain ne supporte RSTP, conceptuellement c'est comme si on connectait deux interfaces physiques du même switch avec un câble...

2) J'avoue que ça m'a un brin tracassé
Alors j'ai monté un rapide petit lab... J'ai pris un swith Cisco 3750 sur lequel j'ai configuré le Spanning Tree, et j'ai monté une daisy-chain avec 2 autres switches sur lesquels j'ai désactivé le Spanning Tree. Et effectivement ça marche, j'ai bien une interface qui passe en Blocking sur le 3750:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
DVP_TEST#sh spanning-tree blockedports

Name                 Blocked Interfaces List
-------------------- ------------------------------------
VLAN10               Fa1/1

Number of blocked ports (segments) in the system : 1

Donc effectivement, avec des équipements comme du Cisco, ça a l'air de fonctionner comme attendu...

3) Dans des implémentations moins "solides" de RSTP, on peut imaginer que le switch puisse devenir zinzin lorsqu'il va recevoir un BPDU sur la 2ème interface (parce qu'il va voir que la MAC adresse source des BPDU est sa propre MAC adresse)...

4) J'ai rencontré des archis qui ressemblent à ça mais avouons que ça sort des sentiers battus... Le seul problème que je vois, c'est en termes de support parce que si un jour le réseau part en vrille, le constructeur des chips Ethernet te demandera probablement de retirer le switch RSTP et d'implémenter HSR/PRP. D'autre part, il faudra demander au constructeur des chips s'il effectue un traitement particulier sur les Multicasts Spanning Tree (j'ai déjà vu des cas de figure où les chips droppaient ces Multicasts de façon "silencieuse", c'est à dire sans incrémenter le moindre compteur Ethernet).

5) Maintenant, si on regarde d'un point de vue cost... Il te faudra un switch qui implémente RSTP sur lequel tu n'utiliseras que 2 interfaces Ethernet... C'est un peu comme prendre un bazooka pour tuer un moustique qui risque de ne passer que tous les 3 ou 4 ans

-VX

[gao.t]

Merci beaucoup pour cette réponse très claire et argumentée.

5) Maintenant, si on regarde d'un point de vue cost... Il te faudra un switch qui implémente RSTP sur lequel tu n'utiliseras que 2 interfaces Ethernet... C'est un peu comme prendre un bazooka pour tuer un moustique qui risque de ne passer que tous les 3 ou 4 ans

Oui c’était ma crainte mais puisque dans le domaine des bus industriels il me semble avoir compris que c'était quelque chose qui se faisait, alors je suis allé voir chez un fabriquant du domaine (MOXA) et j'ai trouvé des switchs qui permettent ce genre de chose. Tourne autour des 200 euros.

4) J'ai rencontré des archis qui ressemblent à ça mais avouons que ça sort des sentiers battus... Le seul problème que je vois, c'est en termes de support parce que si un jour le réseau part en vrille, le constructeur des chips Ethernet te demandera probablement de retirer le switch RSTP et d'implémenter HSR/PRP. D'autre part, il faudra demander au constructeur des chips s'il effectue un traitement particulier sur les Multicasts Spanning Tree (j'ai déjà vu des cas de figure où les chips droppaient ces Multicasts de façon "silencieuse", c'est à dire sans incrémenter le moindre compteur Ethernet).

Alors là, c'est ma plus grande inquiétude. Le KSZ8873 semble être préconisé pour du daisy-chaining mais je ne suis pas convaincu qu'il s'intègre bien dans une solution avec un commutateur qui supporte RSTP. Je suis preneur de l'info. Je pense d'ailleurs à faire l'essai.

La solution HSR me fait moins peur mais est plus chère, sans parler de la difficulté à la mettre en oeuvre. J'ai pensé à ça. Semble être le top, 40 euros la puce quand même, mais je ne sais pas si communiquer avec ce chip est simple.
Il y a aussi ça. ALors là, c'est pas cher, mais j'ai un gros doute sur la difficulté à le manager... et sur le sérieux de la chose.
Mais oui, le HSR me rassurerait.

[Invité]

Tiens, je relisais ce fil et je voulais simplement insister sur le fait que c'est uniquement dans ce type d'infra (mono-bridge STP) qu'un Root Bridge porte une interface Blocking.

A partir du moment qu'il y a au moins 2 bridges dans une instance Spanning Tree, le Root Bridge de l'instance ne portera jamais d'interface Blocking...

La démonstration est évidente (par l'absurde par exemple)

-VX

[gao.t]

Merci encore pour les réponses. Je vais commencer l'évaluation, je posterai mes résultats.

[Invité]

Je viens de jeter un oeil dans la doc du chip et j'ai vu ça:

IEEE 802.1d Rapid Spanning Tree Protocol Support

ce qui est très curieux

Parce que l'IEEE 802.1d est la première version historique du Spanning Tree (du style t'as le temps de prendre un café avant que ça reconverge ).
Et le Rapid Spanning Tree a été standardisé par la norme IEEE 802.1w...


Et en regardant un peu loin dans la doc, j'ai trouvé ceci:

RSTP uses only one type of BPDU called RSTP BPDUs. They are similar to STP Configuration BPDUs with the exception of a type field set to “version 2” for RSTP and “version 0” for STP, and a flag field carrying additional information.

Donc il semble bien que ce chip supporte RSTP !
Et alors là, t'as plus besoin du switch "externe".
Tu configures le RSTP et tu boucles la daisy-chain en connectant le "premier" et le "dernier" KSZ et le tour est joué...

-VX

[gao.t]

Super ! Je ne suis pas allé aussi loin dans la lecture de la datasheet, j'étais encore au stade "constitution d'un panorama des différentes technologies".
J'avoue que ça commence à être intéressant, je vais regarder ça de près. C'est quand même étrange que Microchip ne le mette pas en avant sur la page du chip.