Thank you for the code link, very useful!

I think this answers my question, and it's also as Jen described.

For reference, the traceroute bit I was trying to decypher is below...it looks like the router at hop 3 replies to the traceroute packet, but at the same time forwards it to the next router along the path, which also replies (the duplicates in hop 3's response have the source address of hop 4) - i guess this behaviour is very similar to the 'loops' described in the Paris traceroute paper (https://dl.acm.org/doi/pdf/10.1145/1177080.1177100):

{   'hop': 3,
                      'result': [   {   'from': '2a02:2858:500:8::1',
                                        'rtt': 0.78,
                                        'size': 96,
                                        'ttl': 63},
                                    {   'dup': True,
                                        'from': '2a02:2858:500:3305::2',
                                        'rtt': 4.366,
                                        'size': 96,
                                        'ttl': 62},
                                    {   'from': '2a02:2858:500:8::1',
                                        'rtt': 0.786,
                                        'size': 96,
                                        'ttl': 63},
                                    {   'dup': True,
                                        'from': '2a02:2858:500:3305::2',
                                        'rtt': 4.347,
                                        'size': 96,
                                        'ttl': 62},
                                    {   'from': '2a02:2858:500:8::1',
                                        'rtt': 0.76,
                                        'size': 96,
                                        'ttl': 63},
                                    {   'dup': True,
                                        'from': '2a02:2858:500:3305::2',
                                        'rtt': 4.351,
                                        'size': 96,
                                        'ttl': 62}]},
                  {   'hop': 4,
                      'result': [   {   'from': '2a02:2858:500:3305::2',
                                        'rtt': 4.826,
                                        'size': 96,
                                        'ttl': 62},
                                    {   'from': '2a02:2858:500:3305::2',
                                        'rtt': 5.127,
                                        'size': 96,
                                        'ttl': 62},
                                    {   'from': '2a02:2858:500:3305::2',
                                        'rtt': 4.895,
                                        'size': 96,
                                        'ttl': 62}]},

Thank everyone for the responses!

Ana

Hello Ana,

I took a very quick look in the traceroute code, see here:

ripe-atlas-probe-measurements/traceroute.c at 7c03fba082e93b7a1f0f14cc3769bb31e83909e3 · RIPE-NCC/ripe-atlas-probe-measurements github.com

It seems that a sequence number in the traceroute packet is used. If this sequence number is received back it’s marked as ‘response received’. If another response is received within a certain timeframe, it’s tagged as a duplicate. Otherwise its a late packet.

Hope it helps.

Cheers,

Michel

On 20 Jan 2023, at 11:38, Ana Custura <ana@erg.abdn.ac.uk> wrote:

Hi everyone,

Just a question on how Atlas detects duplicate ('dup') packets in a traceroute.

Is the 'dup' field added to a result when two received packets are exactly the same, regardless of whether they were received for a different initial TTL?

Or are any packets that were unexpectedly received for a specific TTL marked as duplicates (e.g. if you receive 6 replies from 2 different IP addresses to the 3 initial packets sent with TTL 1, will 3 of these replies be marked as duplicates)?

Thanks for your help!

Regards,
Ana
--
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas