uXRCE-DDS bridge multicast UDP addresses and ports

Dear community,

I am running two PX4 autopilot SITL instances with the uXRCE-DDS bridge (micro-xrce-dds-bridge udp4 -p 8888) and I try to understand what address / port is used for each ROS2 topic :

  • I am using Cyclone DDS : RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
  • Each PX4 instance is launched in a separate terminal and restricted to use a unique Network interface
    export CYCLONEDDS_URI=<path_to_this_config_file.xml> :
 <?xml version="1.0" encoding="utf-8"?>
    xsi:schemaLocation="https://cdds.io/config https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/master/etc/cyclonedds.xsd"
    <Domain Id="any">
                <NetworkInterface name='tun0' />
  • Each network interface is assigned an IP address (tun0 is, tun1 is

The second PX4 instance points to a network interface called “tun1”. Routes are configured between the network interfaces, ping works, ros2 demo pub/sub examples also works.

Using a quick Wireshark analysis, i can see the discovery protocol of DDS at play on the UDP multicast address, which I understand.
However, it seems that the PX4 instances are talking to the UDP multicast addresses :

  • with approx. 10 messages per second (UDP traffic)
  • with approx. 1 message per second (UDP traffic)


  • How did the uXRCE-agent decided to use[10317;10318] to create the DDS topics ?
  • Is it something configurable from the uXRCE-DDS client side (PX4 side) ?

If anyone has the knowledge to answer these questions, this would highly help me ! :slight_smile:
Thanks in advance, TB

PS: this setup is in simulation only for now, but ultimately, my questions apply to real-life deployment also, with each UAV having its own network stack, PX4 autopilot and uXRCE-agent on the onboard computer.

1 Like

Hi @Theotime_Balaguer

This confuses me: shouldn’t be see Client API — eProsima Micro XRCE-DDS 2.1.1 documentation and Micro-XRCE-DDS-Agent/config.hpp.in at 9311555dd0edc960f12852f8223c4458d9da39e0 · eProsima/Micro-XRCE-DDS-Agent · GitHub

On the client side you can only specify the IP address and port where the client expect to find the Agent, in simulation it is set to the localhost, port 8888

Hi @Benja

Thank you for your answer. In the OMG’s DDSI-RTPS interoperability specification, the default address and port for the discovery protocol is From DDSI-RTPS v2.5 document :

So, I would say it is normal for the uXRCE-DDS Agent to announce itself on this address / port. I was using the snap package of uXRCE-DDS. I changed it to source installation from github, the behaviour is the same :

While looking in details at the data inside the packets, I noticed these UDP mutlicast flows are actually the publisher/subscriber middleware of Gazebo (the simulator I use)…

So, actually, the uXRCE-DDS bridge is following OMG’s guidelines. :upside_down_face:

For future users that may end-up here, here is my take on the question :

  • The uXRCE-DDS bridge uses to discover other DDS participants
  • When multiple participants subscribe to the same topic, DDS uses UDP multicast to distribute the messages
  • Gazebo simulator transport layer uses the multicast address, don’t get baited (see these lines and this PR)

Thanks Benja for insights on the client side and your help understanding the situation !

1 Like

Glad that you figured it out!

I must say, I still don’t really understand this

Why do you say that is the discover address and port for uXRCE-DDS even if the code says ?

Well, you are right, some unknown magic is at play here…

Fact is that the multicast address is never used in my system, while the Micro-XRCE-DDS bridge is up and running.

At this day, I cannot explain why is not used. :frowning:

Could it be that is used by another process (not the agent) and the agent is just not using the multicast feature?

Hi @Benja,

Your question made me want to try another method, with a “cleaner” environment than my machine, so I came up with a very simple and reproducible process. I set up a network namespace in my linux environment and launch three programs from within the netns :

Wireshark monitors all the UDP multicast groups :

Still no use of So you are probably right, the Agent doesn’t use multicast, which seems smart considering there is only one machine subscribed to its topics.

So, I added a new network namespace, linked it to the first netns (the one running the Agent) and launched another instance of PX4 in it ./PX4-Autopilot/build/px4_sitl_default/bin/px4 -i 1.

If everything goes well, it should launch the uXRCE-DDS Client and activate the discovery protocol on as stated in the docs, but in my case using wireshark I see no message going to this IP address (and the Client-Agent connection doesn’t work for the second UAV).

PS: I can ping one netns from the other and vice-versa, and I see announcements coming from the foreign netns on, so probably not a network problem.
For that matter, I can see the ROS2 topics from the first PX4 in the second network namespace, so the DDS Domain ID is not in cause, there is a DDS connectivity between the two namespaces.

Could it be a bug ?