Chapitre 08
L'anneau MRP

1. Pourquoi un anneau

Une ligne câblée « en étoile » a un talon d'Achille : chaque câble est un point unique de défaillance. Coupe le lien entre deux switches et tout ce qui est derrière tombe. En automatisme, où un arrêt de production coûte cher, on préfère câbler les switches en boucle : chaque switch a deux chemins vers le reste du réseau. Si un câble lâche, le trafic emprunte l'autre sens. C'est la redondance média.

Mais une boucle physique de commutateurs, laissée telle quelle, est une catastrophe : une trame broadcast tourne indéfiniment et sature le réseau en quelques millisecondes — la fameuse tempête de boucle. Il faut donc un protocole qui garde la boucle physiquement fermée (pour la redondance) tout en la maintenant logiquement ouverte (pour éviter la tempête). Côté Siemens, ce protocole est MRP — Media Redundancy Protocol, normalisé IEC 62439-2.

Dans un anneau MRP, un switch joue le rôle de MRM (Media Redundancy Manager) — ici SW-A (192.168.0.240) — et tous les autres sont des MRC (Media Redundancy Clients) — SW-B (.241) et SW-C (.242). Chaque switch dédie deux ports à l'anneau, ses ring ports. L'astuce est là : en fonctionnement normal, le MRM bloque logiquement l'un de ses deux ring ports. L'anneau est bien un cercle de câbles, mais du point de vue du trafic c'est une ligne ouverte à un endroit — chez le manager. Aucune trame ne fait le tour.

2. Les trames de test MRP

Comment le MRM sait-il que sa boucle est intacte ? Il ne fait pas confiance à l'état des liens vu port par port : il teste le tour complet. Périodiquement, le MRM émet une trame MRP_Test par chacun de ses deux ring ports — donc dans les deux sens de l'anneau. Ces trames portent l'Ethertype 0x88E3 et sont envoyées en multicast ; les MRC les relaient de proche en proche sans les traiter.

• Si le MRM reçoit ses propres MRP_Test en retour sur le port opposé → le tour est complet → anneau FERMÉ (sain, redondance disponible). Il maintient son port secondaire bloqué.
• Si les MRP_Test cessent de revenir (plusieurs manqués d'affilée) → le tour est rompu → anneau OUVERT → le MRM débloque son port secondaire pour rétablir le passage, puis prévient tout le monde.

Ce « prévenir tout le monde » se fait avec des trames MRP_TopologyChange : le MRM ordonne aux MRC de vider leur table d'adresses MAC, sans quoi les switches continueraient à envoyer le trafic vers l'ancien chemin, désormais mort. On croise aussi des MRP_LinkChange (LinkUp/LinkDown), qu'un MRC émet vers le MRM pour signaler qu'un de ses ring ports vient de changer d'état — c'est souvent ce qui déclenche la reconfiguration avant même que les MRP_Test ne manquent.

Les ordres de grandeur à avoir en tête :

3. Observer MRP avec tshark

Tout se joue sur l'Ethertype 0x88E3. On filtre à la capture (filtre BPF ether proto) et on affiche le dissecteur mrp :

# Capturer uniquement les trames MRP sur l'interface machine
sudo tshark -i eth0 -f 'ether proto 0x88E3' -Y mrp

Sur un anneau sain, on obtient un flux régulier de MRP_Test, deux « pistes » qui alternent (une par ring port du MRM), espacées d'environ 20 ms :

# Anneau FERMÉ : MRP_Test réguliers, rien d'autre
$ sudo tshark -i eth0 -f 'ether proto 0x88E3' -Y mrp
  1  0.000000  Siemens_A0:24:0a → MRP-Test  MRP  60  MRP_Test, Prio 40960, Ring closed
  2  0.019987  Siemens_A0:24:0a → MRP-Test  MRP  60  MRP_Test, Prio 40960, Ring closed
  3  0.040012  Siemens_A0:24:0a → MRP-Test  MRP  60  MRP_Test, Prio 40960, Ring closed
  4  0.059998  Siemens_A0:24:0a → MRP-Test  MRP  60  MRP_Test, Prio 40960, Ring closed
  5  0.080003  Siemens_A0:24:0a → MRP-Test  MRP  60  MRP_Test, Prio 40960, Ring closed

Une seule MAC source (celle du MRM, SW-A), un intervalle stable, l'état Ring closed : c'est exactement ce qu'on veut voir. Maintenant, débranchons un câble d'anneau et regardons la coupure :

# Instant de la coupure : rafale de LinkChange puis TopologyChange
$ sudo tshark -i eth0 -f 'ether proto 0x88E3' -Y mrp
 42  0.840010  Siemens_A0:24:0a → MRP-Test    MRP  60  MRP_Test, Ring closed
 43  0.851203  Siemens_B1:07:c2 → MRP-Ctrl    MRP  60  MRP_LinkChange, LinkDown
 44  0.851560  Siemens_A0:24:0a → MRP-Ctrl    MRP  60  MRP_TopologyChange, Interval 20
 45  0.853102  Siemens_A0:24:0a → MRP-Ctrl    MRP  60  MRP_TopologyChange, Interval 20
 46  0.856050  Siemens_A0:24:0a → MRP-Ctrl    MRP  60  MRP_TopologyChange, Interval 20
 47  0.860018  Siemens_A0:24:0a → MRP-Test    MRP  60  MRP_Test, Ring open
 48  0.880004  Siemens_A0:24:0a → MRP-Test    MRP  60  MRP_Test, Ring open

La séquence est lisible : un MRC (SW-B) signale un LinkDown, le MRM émet aussitôt une salve de MRP_TopologyChange (pour purger les tables MAC), débloque son port, et ses MRP_Test repartent en Ring open. Après la réparation physique du câble, on verrait la séquence miroir : LinkUp, nouvelle salve de TopologyChange, retour en Ring closed.

4. Détecter l'anneau ouvert — la faute silencieuse

Voici le point le plus important du chapitre. Quand une coupure survient, MRP fait son travail : en moins de 200 ms (souvent bien moins), le passage est rétabli et le procédé continue de tourner. Aucun voyant rouge sur la machine, aucun arrêt, aucune alarme process évidente. Tout va bien… en apparence.

Sauf que la redondance a été consommée. L'anneau est désormais ouvert : il ne reste qu'un seul chemin. Une seconde faute — un autre câble, un autre switch qui redémarre — et cette fois il n'y a plus de secours : c'est l'arrêt de production. L'anneau ouvert est donc une faute silencieuse mais critique : elle ne fait pas de bruit, mais elle a mis l'installation à un pas du gouffre.

Deux façons de la débusquer :

• Sur le fil — les MRP_Test qui restent en Ring open (au lieu de Ring closed) sont le signe direct que le manager n'a pas retrouvé son tour complet. Un tshark -Y mrp de quelques secondes suffit à trancher.
• Sur le switch — l'état de l'anneau est exposé en SNMP par le manager. La MRP-MIB publie notamment mrpRingState (valeurs open(1) / closed(2)), le rôle du nœud (manager / client) et les numéros des deux ring ports. On peut donc surveiller l'état d'anneau sans même capturer, et l'intégrer à une supervision.

5. Reconstituer la topologie de l'anneau

Pour raisonner sur l'anneau, il faut connaître son ordre physique : quel switch est voisin de quel switch, et par quels ports. On ne le devine pas depuis le plan d'adressage IP (l'ordre des adresses ne dit rien du câblage). On le lit avec LLDP (chapitre 3), qui expose chaque voisinage physique port par port.

$ lldpctl SW-A | grep -A2 -E 'Interface|SysName'
Interface:    port-1, via: LLDP
  Chassis:  SysName: SW-B
Interface:    port-2, via: LLDP
  Chassis:  SysName: SW-C

En croisant les voisinages des trois switches, on reconstitue la boucle :

# Voisinage LLDP consolidé (qui parle à qui, par quel port)
SW-A port-1 ─── port-2 SW-B       ← ring port
SW-B port-1 ─── port-2 SW-C       ← ring port
SW-C port-1 ─── port-2 SW-A       ← ring port  → la boucle se referme

La boucle se referme sur elle-même : A → B → C → A. Les deux ports par lesquels chaque switch participe à cette boucle sont ses ring ports ; tous les autres ports mènent à des équipements terminaux (CPU, ET 200SP, poste de diagnostic .71) et ne comptent pas dans l'anneau. Avec ce schéma en main, une trame LinkDown vue au §3 se localise immédiatement : « SW-B a perdu son port-2 » désigne précisément le câble SW-B ↔ SW-C.

6. Mesurer la reconvergence

La théorie annonce « < 200 ms » ou « ~20 ms en rapide ». Mais ce qui compte vraiment, c'est le trou vu par le procédé : pendant combien de temps le cyclique Profinet (chapitre 7) s'est-il réellement interrompu ? On le mesure en capturant en parallèle les trames Profinet RT et l'événement MRP, sur le même horodatage.

# Capturer côté cyclique : trames Profinet RT (0x8892) + MRP (0x88E3)
sudo tshark -i eth0 -f 'ether proto 0x8892 or ether proto 0x88E3' \
     -T fields -e frame.time_relative -e eth.type -e _ws.col.Info

On débranche un câble d'anneau (sur banc !), on laisse tourner quelques secondes, on rebranche, puis on cherche le plus grand écart entre deux trames RT consécutives — c'est le trou :

# Extrait autour de la coupure — on isole le cyclique (0x8892)
1.203  0x8892  RT_CLASS_1  ...        # dernier échange avant la coupure
1.204  0x88e3  MRP_LinkChange, LinkDown
1.205  0x88e3  MRP_TopologyChange
... trou : plus aucune 0x8892 ...
1.271  0x8892  RT_CLASS_1  ...        # reprise du cyclique

Ici, dernière trame RT à 1.203 s, reprise à 1.271 s : le procédé a subi un trou de ~67 ms. On compare cette valeur à deux références : la classe MRP configurée (67 ms est cohérent avec une classe 200 ms, largement dans les clous), et le temps de surveillance du device Profinet (le watchdog, typiquement 3 × la période cyclique). Tant que le trou reste sous le watchdog, le device ne déclare pas de défaut de communication et le procédé ne bronche pas. S'il le dépasse, on verrait une coupure Profinet franche — et là, la reconvergence MRP est trop lente pour la période cyclique choisie.

$ sudo tshark -i eth0 -f 'ether proto 0x8892' -T fields -e frame.time_relative \
   | awk 'NR>1{d=$1-p; if(d>max){max=d}} {p=$1} END{printf "trou max = %.1f ms\n", max*1000}'
trou max = 67.4 ms

Récapitulatif

Exercices

1  0.000000  Siemens_A0:24:0a  MRP_Test, Ring closed
2  0.020015  Siemens_A0:24:0a  MRP_Test, Ring closed
3  0.039992  Siemens_A0:24:0a  MRP_Test, Ring closed
4  0.060008  Siemens_A0:24:0a  MRP_Test, Ring closed

# Capture X
MRP_Test          1500
MRP_TopologyChange   0

# Capture Y
MRP_Test          1490
MRP_TopologyChange  84

$ ethtool -S eth0 | grep -iE 'crc|carrier|error'
     rx_crc_errors: 2417
     carrier_changes: 168

sudo tshark -i eth0 -f 'ether proto 0x8892 or ether proto 0x88E3' \
     -T fields -e frame.time_relative -e eth.type -e _ws.col.Info

$ sudo tshark -i eth0 -f 'ether proto 0x8892' -T fields -e frame.time_relative \
   | awk 'NR>1{d=$1-p; if(d>max)max=d} {p=$1} END{printf "trou = %.1f ms\n", max*1000}'
trou = 67.4 ms