Documentation
Le multicast ne passe pas : diagnostic
VIGIL-MESH réplique le multicast IP à travers le réseau comme sur un même câble : mDNS, SSDP, WS-Discovery et la découverte DDS peuvent atteindre des membres distants. Quand cela ne fonctionne pas, la cause est presque toujours l'une de quatre : un abonnement qui n'est pas détecté, une découverte trop bavarde bridée par le contrôle de tempête, un TTL mal placé, ou un profil tcp-only qui change la donne du fan-out. Cette page passe chaque hypothèse en revue, dans l'ordre où il faut les vérifier.
Vérifier les abonnements
Le premier point à contrôler est l'abonnement. VIGIL-MESH ne réplique une diffusion que vers les membres réellement abonnés au groupe concerné : l'agent joue le rôle de querier IGMPv3 (IPv4) et MLDv2 (IPv6) local sur l'interface de chaque machine, et détecte les abonnements que la pile IP annonce. Si l'abonnement n'est pas vu, rien n'est répliqué.
- Confirmez que l'application côté récepteur a bien rejoint le groupe multicast : c'est elle qui déclenche l'annonce IGMP/MLD que l'agent écoute.
- Un récepteur qui ne s'abonne pas ne recevra rien : la réplication est ciblée, pas diffusée à tout le réseau.
- Vérifiez la famille d'adresses : un abonnement IPv6 relève de MLDv2, un abonnement IPv4 d'IGMPv3. Une application configurée sur la mauvaise famille ne sera pas jointe.
- Après (re)démarrage d'une application réceptrice, laissez le temps à l'abonnement d'être annoncé puis propagé avant de conclure à un échec.
Contrôle de tempête : une découverte bridée
Deuxième hypothèse, souvent la vraie coupable quand « une partie » de la découverte passe et pas le reste : le contrôle de tempête. Pour éviter qu'une diffusion mal bornée dégénère, VIGIL applique un token bucket par émetteur de 200 paquets/s et 512 kbit/s, appliqué à l'émission comme au fan-out. Une découverte trop bavarde peut donc être bridée à sa source.
- Symptôme : une découverte volumineuse (beaucoup d'annonces en rafale) semble incomplète ou intermittente alors que les abonnements sont corrects.
- Cause : l'émetteur dépasse les 200 pps ou 512 kbit/s et voit son trafic de diffusion étranglé au-delà du seuil.
- Piste : réduire le volume de découverte plutôt que de compter sur une diffusion illimitée — restreindre les domaines de découverte, espacer les annonces, limiter le nombre de participants qui s'annoncent simultanément.
- Le comportement du storm control à double étage et ses seuils sont détaillés dans /docs/multicast-avance.
TTL et link-local
Beaucoup de protocoles link-local se protègent en exigeant un TTL de 255 à la réception : si le paquet a été routé — donc décrémenté — ils le rejettent. VIGIL transporte le TTL link-local d'un bout à l'autre sans décrément, si bien qu'un paquet émis avec TTL 255 arrive avec TTL 255. Mais l'émission, elle, dépend de l'application.
- Vérifiez que l'émetteur envoie bien avec le TTL attendu par le protocole (255 pour les piles mDNS strictes). Un TTL trop bas côté application sera rejeté à la réception, quel que soit le transport.
- Ne cherchez pas de décrément côté VIGIL : le TTL link-local n'est pas décrémenté, ce n'est donc pas là qu'un TTL 255 se dégrade.
- Si un récepteur rejette un paquet pourtant bien reçu, suspectez une exigence de TTL côté application avant de suspecter le réseau.
Profil tcp-only : le fan-out passe en TCP
Si un réseau bloque l'UDP, les nœuds concernés basculent sur le profil tcp-only et transitent par la vigie. Le multicast continue d'être répliqué, mais le fan-out emprunte alors du TCP via le relais plutôt qu'un chemin direct. Cela reste fonctionnel ; c'est simplement un chemin différent, à garder en tête pendant le diagnostic.
- Un récepteur en tcp-only reçoit toujours les diffusions auxquelles il est abonné : le profil ne coupe pas le multicast.
- Le fan-out via la vigie ajoute un détour ; combiné à une découverte bavarde, il peut rendre le storm control plus visible.
- Si vous soupçonnez l'UDP d'être en cause, confirmez d'abord la connectivité de base : voir /docs/depannage-nat.
DDS et ROS 2
Les intergiciels DDS — dont s'appuie ROS 2 — utilisent le multicast IP pour la découverte des participants. Comme VIGIL réplique ce multicast, la découverte peut fonctionner à travers le mesh sans passerelle applicative. Mais la découverte DDS est notoirement volubile : de nombreux participants qui s'annoncent produisent un trafic soutenu, susceptible d'approcher le plafond de 200 pps par émetteur et d'être bridé.
- Si la découverte ROS 2 est incomplète, surveillez d'abord le storm control : c'est le suspect le plus probable sur un déploiement réel.
- Restreindre les domaines de découverte DDS réduit le volume d'annonces et évite d'approcher les plafonds.
- Les objectifs, le raisonnement de compatibilité et ce qui reste à démontrer côté ROS 2 sont détaillés dans /docs/cas-ros2.
Questions fréquentes
Mon mDNS ne remonte pas côté distant, par où commencer ?
Une découverte semble incomplète alors que tout est abonné. Pourquoi ?
Le multicast passe-t-il en profil tcp-only ?
Faut-il déclarer les groupes multicast quelque part ?
In English
VIGIL-MESH replicates IP multicast across the mesh, so mDNS, SSDP, WS-Discovery and DDS discovery can reach distant members. When it does not work, check four things in order: subscriptions, storm control, TTL, and the tcp-only profile.
Replication is targeted: a local IGMPv3/MLDv2 querier only propagates to members actually subscribed to a group, so the receiver must have joined it. A chatty discovery can be throttled at source by the per-sender storm control (200 pps / 512 kbit/s) — the fix is to make discovery less noisy, not to lift the limit.
Link-local TTL 255 is carried end to end without decrement, so a rejected packet usually points to an application-side TTL requirement. DDS/ROS 2 discovery rides on this multicast; end-to-end ROS 2 qualification is still on the roadmap.