Intermittent Liveliness Issues, or Sample loss in Non-Multicast Networks

Submitted by scardenete on Thu, 08/06/2026 - 09:41

Overview

The default discovery configuration (multicast_receive_address) uses the UDPv4 multicast address 239.255.0.1. If Connext advertises multicast but runs on an environment without end-to-end multicast support, it can cause intermittent discovery, liveliness issues, and failed reliable-data repairs.

Since Connext 7.3.1+, a participant detects if local interfaces support multicast by checking the MULTICAST flag. If an interface lacks multicast support, the participant will not propagate multicast locators for it (see 7.3.1 Release Notes).

However, a network interface may appear multicast-capable to the operating system (e.g., via the MULTICAST flag or "Multicast: Enabled" status), while the actual network infrastructure does not forward or deliver multicast packets end-to-end. This can occur with certain NICs, virtual interfaces, tunnels, wireless links, or network configurations.

Impact

If a remote participant receives a DATA(p) announcement containing one or more multicast locators, it may use those locators for traffic that Connext sends through multicast. If multicast is not delivered by the network, that traffic will never reach the remote participant. As a result, you may encounter the following issues.

Endpoint Liveliness repeatedly expires and recovers

Endpoint liveliness is continually lost and regained. For example, participant liveliness messages, DATA(m), may be sent through multicast when the remote participant has advertised at least one multicast locator. If the multicast packets cannot traverse the underlying network:

  1. The DATA(m) packets asserted by the participant do not reach the remote participant/reader.

  2. The remote participant/reader eventually considers the local participant/writer stale after lease_duration .

  3. Subsequent discovery traffic or communication through another reachable path (e.g., unicast) can rediscover the participant.

  4. The cycle repeats.

This issue can appear as liveliness being lost and regained at approximately the configured lease_duration interval.

Reliable repair traffic is not delivered

For reliable communication, Connext can send repair traffic through multicast when multicast_resend_threshold is reached. If multicast is unavailable on the actual network path, those repair packets will not reach the remote participant.

Depending on the application QoS and traffic pattern, this issue may result in delayed recovery of missing samples, repeated repair attempts, or samples that are not recovered.

Solution

Keep the participant QoS configuration consistent with the actual capabilities of the network. Either enable multicast on your network, or disable multicast at the DDS level in all participants communicating over the multicast-incompatible network.

For instructions and examples on how to disable multicast in QoS, seeConfigure RTI Connext DDS to not use multicast

Also consider the following:

  • Configure unicast initial_peers so participants can discover each other without multicast.

  • If multicast user data was explicitly configured on readers entities, remove or replace those multicast receive addresses.

  • Do not use a NIC or operating-system multicast flag as the sole validation that multicast is available across the network.

Verification

After applying the configuration:

  1. Inspect participant discovery traffic with Wireshark, Admin Console, or Connext logging.

  2. Confirm that participant announcements ( DATA(p) in wireshark), do not advertise UDP multicast locators such as 239.255.0.1.

  3. Confirm that discovery succeeds through the configured unicast peers or selected discovery service.

  4. Verify that participant liveliness no longer cycles at the configured lease-duration interval.

  5. For reliable traffic, verify that missing-sample recovery does not depend on multicast repair packets.

Product:
Keywords: