Running ROS2 on a Shared Network Without Configuring DDS Is a Network Incident Waiting to Happen

You set up ROS2 on a laptop, connect to the office WiFi, and run a demo. The demo works. What you do not see is that every ROS2 node on your machine is broadcasting multicast discovery packets across the entire subnet, looking for other nodes. On an isolated lab network with three machines, this is harmless. On a shared office network with fifty machines, it is network flooding. ROS2 does this by default.

Why DDS Discovery Is Aggressive By Default

ROS2 uses DDS as its middleware layer. DDS handles node discovery through a protocol called RTPS, which sends multicast packets to a well-known address to announce participants and find matching publishers and subscribers. The default ROS2 configuration uses this multicast approach because it requires zero setup: nodes find each other automatically with no central server.

The problem is scale. Each ROS2 process becomes a DDS participant. Each participant sends periodic multicast announcements. On a network with many ROS2 nodes, the cumulative multicast traffic grows linearly with the number of participants. On a large network, or even a small network with heavy ROS2 traffic, this can overwhelm switches, routers, and wireless access points.

A ROS Discourse thread described this happening: an unconfigured ROS2 system on a shared office network generated enough multicast traffic to trigger IT alerts. The fix was not a code change. It was a 30-line DDS XML configuration file that nobody had written because the defaults were supposed to "just work."

The Two Failure Modes

Unconfigured DDS causes problems in production in two distinct ways. Both are predictable. Neither is hard to prevent.

Network flooding from multicast discovery. This is the default failure mode. Every participant multicasts. Every other participant listens. The traffic is not your application data — it is discovery overhead. On a wired network with managed switches, this is contained. On WiFi, every multicast packet is broadcast to every associated client, consuming airtime and reducing throughput for everyone. Large message types make it worse. A PointCloud2 message at 10Hz fragments into multiple IP packets. Fragmented multicast is expensive to forward and expensive to drop.

Participant isolation from missing configuration. The opposite problem happens when you do try to configure DDS but get it wrong. DDS vendors — FastDDS and CycloneDDS are the two most common in ROS2 — have different default discovery behavior. A node compiled against FastDDS may not see a node compiled against CycloneDDS on the same topic unless both are configured to use the same discovery server or explicit peer list. The symptom is silent: topics exist, messages are published, and some subscribers never receive them. There is no error. There is no warning. ros2 topic list shows the topic on both machines.

How to Fix It Before It Breaks

For most production deployments, the fix is replacing multicast discovery with explicit peer lists or a discovery server.

Option 1: Discovery server. Both FastDDS and CycloneDDS support a centralized discovery server that nodes register with instead of multicasting. The server runs on a known host. Nodes connect to it explicitly. Multicast traffic drops to zero. This is the right approach for multi-machine deployments in controlled environments.

For FastDDS, the configuration is an XML file:

<?xml version="1.0" encoding="UTF-8" ?>
<dds>
  <profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
    <participant profile_name="discovery_server">
      <rtps>
        <builtin>
          <discovery_config>
            <discoveryProtocol>SERVER</discoveryProtocol>
            <discoveryServersList>
              <RemoteServer prefix="44.53.00.5f.45.50.52.4f.53.49.4d.41">
                <metatrafficUnicastLocatorList>
                  <locator>
                    <udpv4>
                      <address>192.168.1.100</address>
                      <port>11811</port>
                    </udpv4>
                  </locator>
                </metatrafficUnicastLocatorList>
              </RemoteServer>
            </discoveryServersList>
          </discovery_config>
        </builtin>
      </rtps>
    </participant>
  </profiles>
</dds>

Set FASTRTPS_DEFAULT_PROFILES_FILE to this file before running your nodes. The server itself is started with fast-discovery-server -i 0 -l 192.168.1.100 -p 11811.

Option 2: Explicit peer list with unicast. For smaller deployments where running a discovery server is overhead, configure unicast discovery with an explicit peer list. Nodes send discovery traffic only to the listed addresses. No multicast. No server.

<?xml version="1.0" encoding="UTF-8" ?>
<dds>
  <profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
    <participant profile_name="unicast_peers">
      <rtps>
        <builtin>
          <initialPeersList>
            <locator>
              <udpv4>
                <address>192.168.1.101</address>
                <port>7412</port>
              </udpv4>
            </locator>
            <locator>
              <udpv4>
                <address>192.168.1.102</address>
                <port>7412</port>
              </udpv4>
            </locator>
          </initialPeersList>
        </builtin>
      </rtps>
    </participant>
  </profiles>
</dds>

Option 3: ROS_DOMAIN_ID isolation. The simplest but most limited fix. Set ROS_DOMAIN_ID to a unique integer per robot or per team. DDS participants only discover others with the same domain ID. This does not reduce multicast — it isolates it. Two robots on the same network with different domain IDs do not interfere. Ten robots with the same domain ID still flood. Use this as a baseline, not a solution.

What Most Teams Get Wrong

The most common mistake is assuming that because the demo worked, the configuration is correct. Demos are run on single machines or small isolated networks. Production is run on shared infrastructure with other teams, other robots, and corporate IT monitoring traffic patterns.

Another common mistake is copying XML snippets from tutorials without understanding whether the configuration targets FastDDS or CycloneDDS. The two vendors use different XML schemas. A FastDDS profile does not work with CycloneDDS. A CycloneDDS config is ignored by FastDDS. If your workspace uses the default RMW and you switch distros, the middleware may change underneath you.

Measuring the Impact Before It Hurts

Before deploying to a shared network, measure your DDS discovery traffic. On Linux:

# Monitor multicast traffic from your machine
sudo tcpdump -i any -n host 239.255.0.1

# Check DDS participant count
ros2 node list | wc -l

Each node is a participant. Each participant generates discovery traffic. If the product of node count and network size is large, you need explicit configuration.

For latency-sensitive control loops, measure end-to-end message delay independently of DDS claims. ros2 topic delay /your_topic gives you timestamp versus arrival time. If latency spikes correlate with network load, your DDS configuration is part of the problem.

What to Take Away

ROS2's default DDS configuration is built for robotics labs: small, isolated, and controlled. It was not built for offices, production floors, or multi-robot fleets. The defaults make first demos easy and production deployments unreliable.

The fix is straightforward: a 30-line XML file that switches discovery from multicast to unicast or a discovery server. Most teams write this file only after something breaks. By then, the network flooding has happened. The IT ticket has been filed. The robot has already misbehaved in front of a customer.

Configure DDS before you need to. The default is a demo setting. Production needs explicit control over who talks to whom.