How do I configure DDS to work with multiple network interfaces?

You cannot specify which NICs DDS will use to send data.  You can restrict the NICs that DDS can use to receive data by configuring Participant properties in the QoS on the DataReader, but you cannot tell DDS to use one NIC or another to send the DataWriter data.  Rather, the DataWriter will try to send data to all of the addresses that a DataReader announces when subscribing to data using the interfaces that the Operating System selects.

In other words, it is up to the routing table on the Operating System (OS) to decide which NICs are used to send the UDP/IP packets.

For example,

• DataReader1 is on a node with single NIC, IP address 10.30.1.100
• DataReader2 is on a node with single NIC, IP address 10.10.100.120
• DataReader3 is on a node with two NICs, IP addresses 10.30.1.101 and 10.10.100.121
• The DataWriter1 is on a node with two NICs, IP addresses 10.30.1.191 and 10.10.100.188
• The netmask for all networks is 255.255.255.0.
• The DataWriter and DataReaders are for the same topic and have compatible QoS.  Assume that the DataReaders are NOT subscribing to data using multicast.

In this scenario when DataWriter1 sends data to DataReader1, it will send a packet using the address 10.30.1.100. When sending data to DataReader2, it will send a packet using the address 10.10.100.120. When sending data to DataReader3, it will send 2 packets using the addresses 10.30.1.101 and 10.10.100.121.

The NIC used by the OS to send the data from DataWriter1 to a particular destination depends on the network routing table for the machine where DataWriter1 is running.  Absent strange OS configurations, packets destined to the 10.30.1.x network should be sent through the NIC with address 10.30.1.191, and packets destined to the 10.10.100.x network should be sent through the NIC with address 10.10.100.188.

For example, the routing table (use netstat -r to see the routing table, example below is output on Windows) may be:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0        10.10.0.1    10.10.100.188     10
          0.0.0.0          0.0.0.0        10.30.1.1      10.30.1.191     25
      10.10.255.0    255.255.255.0         On-link     10.10.100.188    266
    10.10.100.188  255.255.255.255         On-link     10.10.100.188    266
    10.10.100.255  255.255.255.255         On-link     10.10.100.188    266
        10.30.1.0    255.255.255.0         On-link       10.30.1.191    281
      10.30.1.191  255.255.255.255         On-link       10.30.1.191    281
      10.30.1.255  255.255.255.255         On-link       10.30.1.191    281
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link     10.10.100.188    266
        224.0.0.0        240.0.0.0         On-link       10.30.1.191    281
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link     10.10.100.188    266
  255.255.255.255  255.255.255.255         On-link       10.30.1.191    281
===========================================================================

Which supports the scenario as described above.

Restricting interfaces on the DomainParticipant

With the Property DomainParticipantQos, you can modify the default NICs that the DomainParticipant is allowed to use (or denied), for example:

<participant_qos>
  <property>
    <value>
      <element>
        <name>dds.transport.UDPv4.builtin.parent.allow_interfaces_list</name>
        <value>192.168.0.1,192.168.1.2</value>
      </element>
      <element>
        <name>dds.transport.UDPv4.builtin.parent.deny_interfaces_list</name>
        <value>192.168.2.3 </value>
      </element>                   
    </value>
  </property>
</participant_qos>

How restricting interfaces on the DomainParticipant affect the DataReader

Absent further configuration, a DataReader will only advertise the interfaces that its DomainParticipant has been allowed to use as addresses where it can receive data.  So for example, if DataReader3's participant is restricted to use only the NIC with IP address 10.10.100.121, then this will be the only NIC advertised by DataReader3 and therefore a DataWriter will only send data to the DataReader3 at address 10.10.100.121.  However, the DataWriter may still use its 10.10.100.188 NIC when sending data to DataReader2, which is on the same subnet as DataReader3.

How restricting interfaces on the DomainParticipant affect the DataWriter

Restricting interfaces has no effect on DataWriters as far as unicast data is concerned.  As mentioned earlier for unicast data, an application cannot control which NIC card is used by a DataWriter to send data.  Generally speaking and independently of DDS, there is no way to control which interface IP data is sent at the application level.  This is entirely controlled by the OS routing table.

For multicast data, the DomainParticipant will only send out multicast packets using the interfaces that it's been allowed to use.

NOTE: In versions of Connext DDS prior to 5.3.0, by default, a DomainParticipant is only able to announce the first 4 interfaces that it finds as the default set of addresses to which other DomainParticipants should send it data. In Connext DDS 5.3.0 and higher, this limit has increased to the first 16 interfaces.