Documentation

Multicast not getting through: diagnosis

VIGIL-MESH replicates IP multicast across the network as if on a single wire: mDNS, SSDP, WS-Discovery and DDS discovery can reach distant members. When it does not work, the cause is almost always one of four: a subscription that is not detected, an overly chatty discovery throttled by storm control, a misplaced TTL, or a tcp-only profile that changes the fan-out picture. This page reviews each hypothesis, in the order in which to check them.

Check the subscriptions

The first thing to check is the subscription. VIGIL-MESH only replicates a broadcast to the members actually subscribed to the group concerned: the agent acts as the local IGMPv3 (IPv4) and MLDv2 (IPv6) querier on each machine's interface, and detects the subscriptions the IP stack announces. If the subscription is not seen, nothing is replicated.

Confirm that the application on the receiving side has actually joined the multicast group: it is what triggers the IGMP/MLD announcement the agent listens for.
A receiver that does not subscribe will receive nothing: replication is targeted, not broadcast to the whole network.
Check the address family: an IPv6 subscription falls under MLDv2, an IPv4 subscription under IGMPv3. An application configured on the wrong family will not be reached.
After (re)starting a receiving application, allow time for the subscription to be announced then propagated before concluding failure.

Storm control: a throttled discovery

Second hypothesis, often the real culprit when “part” of the discovery gets through and the rest does not: storm control. To prevent a poorly bounded broadcast from getting out of hand, VIGIL applies a per-sender token bucket of 200 packets/s and 512 kbit/s, enforced at emission as well as at fan-out. An overly chatty discovery can therefore be throttled at its source.

Symptom: a large discovery (many announcements in bursts) seems incomplete or intermittent even though the subscriptions are correct.
Cause: the sender exceeds 200 pps or 512 kbit/s and sees its broadcast traffic throttled beyond the threshold.
Lead: reduce the discovery volume rather than counting on unlimited broadcast — restrict discovery domains, space out announcements, limit the number of participants announcing themselves simultaneously.
The behaviour of the two-stage storm control and its thresholds are detailed in /en/docs/multicast-avance.

TTL and link-local

Many link-local protocols protect themselves by requiring a TTL of 255 on receipt: if the packet has been routed — and therefore decremented — they reject it. VIGIL carries the link-local TTL end to end without decrement, so a packet sent with TTL 255 arrives with TTL 255. Emission, however, depends on the application.

Check that the sender emits with the TTL the protocol expects (255 for strict mDNS stacks). A TTL set too low on the application side will be rejected on receipt, whatever the transport.
Do not look for a decrement on the VIGIL side: the link-local TTL is not decremented, so that is not where a TTL of 255 degrades.
If a receiver rejects a packet that was in fact received, suspect an application-side TTL requirement before suspecting the network.

tcp-only profile: fan-out goes over TCP

If a network blocks UDP, the nodes concerned fall back to the tcp-only profile and transit through the vigie. Multicast keeps being replicated, but the fan-out then rides TCP via the relay rather than a direct path. It remains functional; it is simply a different path, to keep in mind during diagnosis.

A receiver in tcp-only still receives the broadcasts it is subscribed to: the profile does not cut off multicast.
Fan-out via the vigie adds a detour; combined with a chatty discovery, it can make storm control more visible.
If you suspect UDP is the cause, first confirm basic connectivity: see /en/docs/depannage-nat.

DDS and ROS 2

DDS middlewares — on which ROS 2 relies — use IP multicast for participant discovery. Since VIGIL replicates this multicast, discovery can work across the mesh without an application gateway. But DDS discovery is notoriously talkative: many participants announcing themselves produce sustained traffic, liable to approach the per-sender ceiling of 200 pps and be throttled.

If ROS 2 discovery is incomplete, watch storm control first: it is the most likely suspect in a real deployment.
Restricting DDS discovery domains reduces the announcement volume and avoids approaching the ceilings.
The objectives, the compatibility reasoning and what remains to be demonstrated on the ROS 2 side are detailed in /en/docs/cas-ros2.

Frequently asked questions

My mDNS does not show up on the remote side, where do I start?

First confirm that the receiver is actually subscribed to the group (the IGMPv3/MLDv2 querier must see the announcement), then check the TTL on the sender side (255 for strict stacks). If both are correct but the discovery is large, suspect storm control.

A discovery seems incomplete even though everything is subscribed. Why?

Most likely storm control: beyond 200 pps or 512 kbit/s per sender, broadcast is throttled. Make the discovery less chatty rather than trying to lift the limit.

Does multicast get through on the tcp-only profile?

Yes. A receiver in tcp-only receives the broadcasts it is subscribed to; the fan-out simply rides TCP via the vigie instead of a direct path.

Do multicast groups need to be declared somewhere?

No. The system's IP stack announces the subscriptions and the agent listens to them. There is no group to configure by hand — but the subscription on the receiving side must exist for there to be anything to propagate.