Skip to content

Document DDS multicast address, UDP port and ROS_DOMAIN_ID relationship. - #75

Open
fujitatomoya wants to merge 1 commit into
mainfrom
issue-62-multicast-address-domain-id
Open

fujitatomoya wants to merge 1 commit into
mainfrom
issue-62-multicast-address-domain-id

Conversation

@fujitatomoya

Copy link
Copy Markdown
Owner

Closes #62

Adds Multicast Group Address, UDP Port and ROS_DOMAIN_ID to Enable Multicast and a matching Trouble Shooting entry.

Note

The verification result differs from the premise in the issue. With Fast DDS and Cyclone DDS (RTPS defaults), the multicast group address stays 239.255.0.1 for every ROS_DOMAIN_ID; the domain ID is encoded into the UDP port (7400 + 250 * ROS_DOMAIN_ID for SPDP multicast), not into the address such as 239.255.<ID/256>.<ID%256>. Cilium multicast forwards by group address regardless of the port, so one cilium multicast add --group-ip 239.255.0.1 covers all domains. Please double check against the environment where 239.255.0.1 did not work for another domain ID, that might have been a user-defined multicast locator (XML profile) or a different RMW.

Documented:

  • RTPS default port mapping table (SPDP multicast 7400 + 250 * d, user multicast 7401 + 250 * d, unicast ports with participant ID), and the 0 - 232 domain ID limit
  • Verification with Hubble: talker (kind-worker) and listener (kind-worker2) discover each other with ROS_DOMAIN_ID=42 (Fast DDS, 239.255.0.1:17900) and ROS_DOMAIN_ID=7 (Cyclone DDS, 239.255.0.1:9150), hubble observe --to-ip 239.255.0.1 in the cilium-agent container shows the flows (Multicast handled verdict is reported as DROPPED because the eBPF multicast datapath consumes and replicates the packet)
  • Cases that do need another multicast group: user-defined DDS multicast locators (Fast DDS / Cyclone DDS XML), rmw_zenoh scouting 224.0.0.224:7446 (link-local scope), Gazebo Transport discovery 239.255.0.7:10317, with cilium multicast add --group-ip 239.255.0.7 as the example
  • Trouble Shooting: ROS 2 nodes with ROS_DOMAIN_ID cannot discover each other, how to check with Hubble

Verification

kind v0.33.0 (Kubernetes v1.37.0) 3 nodes + Cilium 1.20.2 (multicast-enabled=true, group 239.255.0.1 only), tomoyafujita/ros:rolling built from docker/Dockerfile.rolling. The Hubble output in the doc is copied from the run, the UDP ports were also confirmed with tcpdump in an ephemeral debug container (10.244.1.180.39513 > 239.255.0.1.17900, 10.244.1.42.46227 > 239.255.0.1.9150). codespell --config codespell.cfg passes.

🤖 Generated with Claude Code

Add "Multicast Group Address, UDP Port and ROS_DOMAIN_ID" to the Enable
Multicast section. The DDS well-known multicast group 239.255.0.1 is
independent from the domain ID, RTPS encodes the domain ID into the UDP
port (7400 + 250 * domainId for SPDP multicast). Cilium multicast
forwards by group address regardless of the port, so one group is
enough for all ROS 2 domains.

Verified on kind v0.33.0 with Cilium 1.20.2: talker and listener on
different nodes discover each other with ROS_DOMAIN_ID=42 (Fast DDS,
239.255.0.1:17900) and ROS_DOMAIN_ID=7 (Cyclone DDS, 239.255.0.1:9150)
with only 239.255.0.1 configured, observed with hubble observe in the
cilium-agent container.

Also list the cases that need another multicast group (user-defined DDS
locators, rmw_zenoh scouting 224.0.0.224:7446, Gazebo Transport
239.255.0.7:10317) and add a Trouble Shooting entry.

Closes #62

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

add how to calculate the DDS multicast address based on Domain ID

1 participant