Hi,
We need DDS to be picked up over multiple subnets. I know that the default Multicast TTL setting is 1, which won't alllow this. I found the article here:
http://community.rti.com/kb/how-do-i-change-multicast-time-live-ttl
and implemented method 3. However, nothing has changed. DDS is not picked up on other subnets and using Wireshark I can see the router on the other subnet saying that the TTL value is 1 and it doesn't have any addresses on the subnet it came from. Below is the snippet of our qos_profiles.xml that contains the setting. Please let me know if you have any idea as to why this setting is not being set.
<?xml version="1.0"?>
<dds
version="5.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="schema.xsd"
>
<qos_library name="quality_QosLibrary">
<qos_profile name="Base_1" is_default_qos="true">
<participant_qos>
<discovery>
<initial_peers>
<!--Integration IPs-->
<element>192.168.10.24</element>
<element>192.168.10.26</element>
<element>192.168.10.70</element>
<element>192.168.10.71</element>
<element>192.168.10.72</element>
<element>192.168.10.73</element>
<element>192.168.200.12</element>
<element>192.168.201.22</element>
</initial_peers>
</discovery>
<transport_builtin>
<mask>MASK_DEFAULT</mask>
</transport_builtin>
<resource_limits>
<type_code_max_serialized_length>8192</type_code_max_serialized_length>
<participant_property_string_max_length>4096</participant_property_string_max_length>
</resource_limits>
<receiver_pool>
<buffer_size>65530</buffer_size>
</receiver_pool>
<property>
<value>
<element>
<name>dds.clock.internal_clock</name>
<value>monotonic,realtime</value>
</element>
</value>
<value>
<element>
<name>dds.clock.external_clock</name>
<value>realtime</value>
</element>
</value>
<value>
<element>
<name>dds.transport.UDPv4.builtin.multicast_ttl</name>
<value>2</value>
</element>
</value>
</property>
</participant_qos>
</qos_profile>
I should have mentioned, I'm running DDS 5.0.0, upgrading at this time is not an option.
Hi,
First off - TTL is only configurable for multicast packets. All of the initial peers in your configuration are unicast IP addresses, which means the configured TTL setting is not used.
If you are using multicast announcements for discovery, or multicast for receiving data, then you should see the TTL reflect the value you have configured. However - the processing of TTL can vary amongst routers. You may need to set a much larger TTL depending on your network. Have you tried using ping to determine the needed TTL across the network?
Lastly - how are you loading the XML configuration? I see that you use the "is_default_qos" attribute. Are you explicitly loading the XML file from within your code? Using the NDDS_QOS_PROFILES environment variable? Or have you named your file USER_QOS_PROFILES.xml? I ask because I want to ensure that the qos changes are actually loaded by RTI. A quick test is to introduce an error in the XML (e.g., bad formatting, mismatched tags) and then start your application. If RTI doesn't report any parse errors, then the Qos file you think you are using isn't actually loaded by RTI.
Hi,
Thanks for your response. I'll go through your bullets below;
1) The initial peers are used as a workaround for the TTL value not being set. However, I have tried an extremely simplified version (The exact example in the link I provided with no other fields) and I have the same result.
2) The TTL value is working and seen correctly by our routers when we used nddsping and the -discoveryTTL parameter. However, if we specify the qos file with nddsping (or any of our software) instead of using the -discoveryTTL switch, the value is no longer set.
3) I have tried all examples you mentioned to load the QOS profile with no success. I have set the environment variable and it is named USER_QOS_PROFILES.xmlI if load a false qos profile, it does error.
Thanks again for your help.
-Ben
Hi,
Which version of RTI and which operating system are you using?
I've attached a simple Windows VS2010 project for RTI Connext 5.1.0 that correctly sets the TTL on my machine. Can you give it a try and let me know the TTL that you see? I verify the TTL by running Wireshark on my machine with the filter 'rtps2', and inspecting the TTL field of the multicast discovery packets.
Hi,
We are using 5.0.0 and Centos 6.4. I cannot update to 5.1. Do you know if this setting works in 5.0.0?
I know the community guide says versions higher than 4.3, but can you verify 5.0.0?
Thanks,
-Ben
Hi Ben,
Attached is an example that uses 5.0.0 on CentOS 6.4 (RTI architecture: x64Linux2.6gcc4.4.5). I copied the XML you provided in the original post, but changed the initial peers to use the multicast address 239.255.0.11. I also changed the ttl value to 7, to make sure that I was picking up my changes. Here's what a tcpdump capture on the sending machine shows:
As you can see, the TTL is indeed set to 7. The attached example is the vanilla rtiddsgen generated example for Foo.idl, but using your QoS settings. Please give it a try and let me know if it works for you.
Another question: are you using a firewall or is the iptables modified to override the TTL setting?
-- edit 12:05PM
I've updated the example publisher to explicitly load the QoS file. I've renamed the file from USER_QOS_PROFILES.xml to ttl.xml, and the Foo_publisher.cxx application will explicitly load "ttl.xml", and call create_participant_with_profile() using the profile defined in the XML file. This was an additional check to make sure the right profile is loaded.
Note that you can also verify the ttl via the command line:
# tcpdump -v -i eth0 host 239.255.0.11
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:04:18.419526 IP (tos 0x0, ttl 7, id 0, offset 0, flags [DF], proto UDP (17), length 420)
centos64-64-dev.rti.com.45698 > 239.255.0.11.rtps-discovery: UDP, length 392
12:04:18.422403 IP (tos 0x0, ttl 7, id 0, offset 0, flags [DF], proto UDP (17), length 420)
centos64-64-dev.rti.com.45698 > 239.255.0.11.rtps-discovery: UDP, length 392
12:04:19.422529 IP (tos 0x0, ttl 7, id 0, offset 0, flags [DF], proto UDP (17), length 420)
centos64-64-dev.rti.com.45698 > 239.255.0.11.rtps-discovery: UDP, length 392
12:04:20.422652 IP (tos 0x0, ttl 7, id 0, offset 0, flags [DF], proto UDP (17), length 420)
centos64-64-dev.rti.com.45698 > 239.255.0.11.rtps-discovery: UDP, length 392
Hello,
Thank you for your continued help. I have not had a chance to test the package you attached, however I did try changing the initial peers to multicast and nothing changed. I do not have a firewall enabled.
Something I noticed this time that may be relevant: The initial peers section was ignored in the QoS file. However, if I set the NDDS_DISCOVERY_PEERS environment variable, then it sent it to the multicast address I requested (the TTL value was still 1 however). I know the application isn't ignoring the QoS file because if I put something invalid it will error and call out the invalid line. Any idea why it's ignoring the Initial Peers in the QoS file? Maybe this is why it's ignoring the TTL value?
Thanks,
-Ben
Hi, I am attaching a generic programs code that we are using to test this. Is there something we need to add to our application code?
Hi Ben,
Thanks for your program. I have it running, and I have it using my configured ttl (=7). I did not need to make any changes to your code to use a different TTL value. Here's what I did to run:
java -classpath $NDDSHOME/class/nddsjava.jar:.:./commons-cli-1.2/commons-cli-1.2.jar HelloDDS -d 11 -p Base_1 -l quality_QosLibrary -wThis is what tcpdump shows:
gotham:ipv6 sumeet$ tcpdump -v -i en1 host 239.255.0.11
tcpdump: listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes
14:33:51.245076 IP (tos 0x0, ttl 7, id 26248, offset 0, flags [none], proto UDP (17), length 484)
192.168.8.103.54707 > 239.255.0.11.10150: UDP, length 456
14:33:52.245231 IP (tos 0x0, ttl 7, id 8176, offset 0, flags [none], proto UDP (17), length 484)
192.168.8.103.54707 > 239.255.0.11.10150: UDP, length 456
14:33:54.243443 IP (tos 0x0, ttl 1, id 56502, offset 0, flags [none], proto IGMP (2), length 32, options (RA))
192.168.8.103 > 239.255.0.11: igmp v2 report 239.255.0.11
14:34:18.241411 IP (tos 0x0, ttl 7, id 1294, offset 0, flags [none], proto UDP (17), length 484)
192.168.8.103.54707 > 239.255.0.11.10150: UDP, length 456
14:34:48.241589 IP (tos 0x0, ttl 7, id 4451, offset 0, flags [none], proto UDP (17), length 484)
192.168.8.103.54707 > 239.255.0.11.10150: UDP, length 456
The packet with ttl=1 is from the IGMP protocol, and is not an RTPS packet.
One thing I did notice in your code: you create the topic using a given QoS profile (e.g. by calling create_topic_with_profile()), but you use the default qos for the DomainParticipant, DataWriter, and DataReader. With RTI Connext DDS, the topic QoS is mostly unused. You'll want to configure the QoS directly on the participant, reader, and writer. I would suggest you change your code to create each of the entities with the given QoS profile (e.g. call create_participant_with_profile()). That way you can be certain that you are actually loading the QoS profile you expect.
Can you try running your example with the file ttl.xml?
-sumeet
Hi, that worked, thanks! It looks like that combination (Initial peers being a multicast address, and also having a multicast receive address) was the key. Thanks again for your help!