Table of Contents

Use of TTL values by 'ntpd'

ntpd uses a table with up to 8 TTL values, called sys_ttl.


The ttl values that can be specified as option for certain operating modes (broadcast …, manycastclient …, etc.) are intended as index numbers to the sys_ttl table.


According to the bitkeeper repository of the NTP project, this has been introduced by a patch that was applied on 2001-12-31, so this should be in the release versions since ntp-4.1.1.


Anyway, as of ntp-4.2.8p15, the HTML documentation partly differs from the implementation, and the implementation behaves in a somewhat unexpected way.


The TTL Table

The default entries of the sys_ttl table are values with a multiple of 32, i.e.:

0, 32, 64, 96, 128, 160, 192, 224


The HTML doc at the bottom of miscopt.html says:

ttl hop …

This command specifies a list of TTL values in increasing order. up to 8 values can be specified. In manycast mode these values are used in turn in an expanding-ring search. The default is eight multiples of 32 starting at 31.

It's not clear what the 31 at the end of the sentence means. Obviously, the first table entry is 0.


Anyway, a line with the ttl keyword at the beginning can be added to the config file to override the default values. For example, a line

ttl 3 5 7 9

in the configuration file results in a table with only 4 entries, i.e.:

3 5 7 9


Specific TTL Values for Specific Modes

The HTML page confopt.html explains the options that can be used to specifiy the TTL value to be used for specific modes of operation. So this option can be appended to other configuration lines like broadcast …, manycastclient …, etc.

ttl ttl

This option specifies the time-to-live ttl for the broadcast command and the maximum ttl for the expanding ring search used by the manycastclient command. Selection of the proper value, which defaults to 127, is something of a black art and should be coordinated with the network administrator. This option is invalid with type r addresses.

This documentation is wrong in several ways.

In fact, the ttl value specified as an option to other commands is an index to the 'sys_ttl' table mentioned above. If the specified value exceeds the maximum suitable index (e.g. 7 for a table with 8 entries), the index number is clamped to the maximum value (e.g. 7 in this example).

The documentation distinguishes between different types of IP addresses with specific characteristics:

So the sentence “This option is invalid with type r addresses.” implies that the option can be used with all modes where a specific IP address needs to be specified, except with the pseudo-IP addresses used for refclocks (type r).


Also, the HTML page discover.html says:

Broadcast/Multicast Scheme

A broadcast server generates messages continuously at intervals by default 64 s and time-to-live by default 127. These defaults can be overridden by the minpoll and ttl options, respectively.


However, in fact these docs aren't quite correct.

According to some tests, all of the following types of UDP packets always use a TTL value of 64 (not even the 127 mentioned in the docs quoted above):


Also, the ttl option has no effect on broadcast packets to IPv4 broadcast addresses.

The only modes of operation that make use of the sys_ttl table are:


Normal Unicast Packets

According to some tests, client requests sent to remote servers as well as server responses sent in reply to client requests are always sent with TTL 64.

Even though it seem legitimate to specify a ttl option with a server command, e.g.

server a.b.c.d ttl 4

the ttl option doesn't seem to have any effect, neither as direct value, nor as index to the sys_ttl table.

There doesn't seem to be a way to change the TTL that is used.


Broadcast Packets to an IPv4 Broadcast Address

Unlike mentioned in the docs quoted above, some tests revealed that broadcast packets sent as server to an IPv4 broadcast address are always sent with TTL 64, not even with TTL 127.

So the ttl option doesn't seem to have any effect, neither as direct value, nor as index to the sys_ttl table. This is similar to the behavior of the normal unicast packets, and there doesn't seem to be a way to change the TTL that is used.

:!: Please note that broadcast packets to a multicast address are handled differently.


Multicast Packets, i.e. Broadcast Packets to a Multicast Address

In multicast server mode, the contents of the sys_ttl table is taken into account.

If a ttl option is specified in the configuration, as in

broadcast 244.0.1.1 ttl 4

the value 4 in this example is used as index to the sys_ttl table, so with the default TTL table, the effectice TTL value is 128.

If no ttl option is specified above, the default ttl option (index) seems to be 0, and if the first value in sys_ttl (with index 0) is 0, as by default, the effective TTL value in the transmitted packets is incremented to 1.

:!: Multicast packets sent in 'manycastclient' mode as well as broadcast packets to IPv4 broadcast addresses are handled in different ways.


Manycast Packets, i.e. Multicast Packets Sent in 'manycastclient' Mode

Unlike broadcast and normal multicast packets which are sent by NTP servers, manycast packets are multicast packets sent by NTP clients to discover NTP servers in the network neighborhood.


The HTML page discover.html says:

Manycast Scheme

A manycast client is configured using the manycastclient configuration command, which is similar to the server configuration command. It sends ordinary client mode messages, but with a broadcast address rather than a unicast address and sends only if less than maxclock associations remain and then only at the minimum feasible rate and minimum feasible time-to-live (TTL) hops. The polling strategy is designed to reduce as much as possible the volume of broadcast messages and the effects of implosion due to near-simultaneous arrival of manycast server messages. There can be as many manycast client associations as different addresses, each one serving as a template for future unicast client/server associations.


Also, RFC-5905 chapter 3.1., 'Dynamic Server Discovery' says:

A manycast client continues sending packets to search for a minimum number of associations. It starts with a TTL equal to one and continuously adding one to it until the minimum number of associations is made or when the TTL reaches a maximum value.


But in fact, ntpd starts with index 1, and the index number is incremented if subsequent packets are being sent. The index is incremented until the maximum index (sys_ttlmax) for the sys_ttl table is reached, and due to the start with index 1 instead of 0, the first entry of the sys_ttl table is completely ignored.

So with the default 'sys_ttl' table the TTL values in subsequent multicast packets sent by a manycast client after start are:

32, 64, 96, 128, 160, 192, 224, 224, 224, …

This looks pretty inappropriate for a discovery scheme for the local network neighborhood.


Things are even worse if you specify a ttl option for the manycastclient command, e.g.

manycastclient 224.0.1.1 ttl 4

In this case, the TTL values in subsequent multicast packets sent by a manycast client after start are

128, 160, 192, 224, 224, 224, …


This doesn't sound like the intended behavior for the manycast server discovery scheme.


Martin Burnicki martin.burnicki@meinberg.de, last updated 2021-08-12