Pour une fois, je crois que je ne vais pas être d'accord avec vous 
Steph m'avait suggéré il y a quelques jours de faire le même test avec la 1e passerelle derrière ma box, en l'occurence 10.2.0.143.

J'ai sorti l'analyseur de réseau, et voici ce que j'observe :
le traceroute balance des paquets ICMP avec des TTL croissants, sans attendre le 1er retour ICMP TTL Exceeded.
En revance, mtr est plus civilisé.
Si mon tcpdump ne s'emmêle pas les pinceaux dans les horodatages et l'ordre de réception des paquets, je pense donc que le "ping pong" observé est plutôt lié à un effet de bord du fonctionnement de traceroute.

J'ai concaténé les 2 fenêtres terminal pour montrer la trace correspondant à chaque commande :

Code: [Sélectionner]

$ mtr -n -c 1 -r 10.2.0.143
Start: 2022-05-04T14:33:47+0200
HOST: fedora                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%     1    3.5   3.5   3.5   3.5   0.0
  2.|-- 10.2.0.143                 0.0%     1    5.3   5.3   5.3   5.3   0.0


$ sudo tcpdump -nvvv icmp or host 10.2.0.143
dropped privs to tcpdump
tcpdump: listening on wlp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:33:47.652580 IP (tos 0x0, ttl 1, id 30834, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63496, seq 33000, length 44
14:33:47.655963 IP (tos 0xc0, ttl 64, id 2865, offset 0, flags [none], proto ICMP (1), length 92)
    192.168.1.1 > 192.168.1.50: ICMP time exceeded in-transit, length 72
IP (tos 0x0, ttl 1, id 30834, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63496, seq 33000, length 44
14:33:47.752624 IP (tos 0x0, ttl 2, id 30845, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63496, seq 33001, length 44
14:33:47.757803 IP (tos 0x0, ttl 63, id 39970, offset 0, flags [none], proto ICMP (1), length 92)
    10.2.0.143 > 192.168.1.50: ICMP time exceeded in-transit, length 72
IP (tos 0x0, ttl 1, id 30845, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63496, seq 33001, length 44
14:33:47.852736 IP (tos 0x0, ttl 3, id 30873, offset 0, flags [none], proto ICMP (1), length 64)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63496, seq 33002, length 44


$ sudo traceroute -I -q1 -n 10.2.0.143
traceroute to 10.2.0.143 (10.2.0.143), 30 hops max, 60 byte packets
 1  192.168.1.1  5.307 ms
 2  10.2.0.143  7.865 ms
 3  *
 4  10.2.0.5  7.849 ms
 5  10.2.0.4  7.842 ms
 6  10.2.0.143  7.834 ms


14:35:38.706967 IP (tos 0x0, ttl 1, id 13905, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 1, length 40
14:35:38.707001 IP (tos 0x0, ttl 2, id 13906, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 2, length 40
14:35:38.707008 IP (tos 0x0, ttl 3, id 13907, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 3, length 40
14:35:38.707016 IP (tos 0x0, ttl 4, id 13908, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 4, length 40
14:35:38.707024 IP (tos 0x0, ttl 5, id 13909, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 5, length 40
14:35:38.707033 IP (tos 0x0, ttl 6, id 13910, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 6, length 40
14:35:38.707042 IP (tos 0x0, ttl 7, id 13911, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 7, length 40
14:35:38.707050 IP (tos 0x0, ttl 8, id 13912, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 8, length 40
14:35:38.707058 IP (tos 0x0, ttl 9, id 13913, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 9, length 40
14:35:38.707066 IP (tos 0x0, ttl 10, id 13914, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 10, length 40
14:35:38.707073 IP (tos 0x0, ttl 11, id 13915, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 11, length 40
14:35:38.707082 IP (tos 0x0, ttl 12, id 13916, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 12, length 40
14:35:38.707090 IP (tos 0x0, ttl 13, id 13917, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 13, length 40
14:35:38.707099 IP (tos 0x0, ttl 14, id 13918, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 14, length 40
14:35:38.707107 IP (tos 0x0, ttl 15, id 13919, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 15, length 40
14:35:38.707115 IP (tos 0x0, ttl 16, id 13920, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 16, length 40
14:35:38.712237 IP (tos 0xc0, ttl 64, id 2866, offset 0, flags [none], proto ICMP (1), length 88)
    192.168.1.1 > 192.168.1.50: ICMP time exceeded in-transit, length 68
IP (tos 0x0, ttl 1, id 13905, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 1, length 40
14:35:38.712328 IP (tos 0x0, ttl 17, id 13921, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 17, length 40
14:35:38.714863 IP (tos 0x0, ttl 62, id 660, offset 0, flags [none], proto ICMP (1), length 88)
    10.2.0.4 > 192.168.1.50: ICMP time exceeded in-transit, length 68
IP (tos 0x0, ttl 1, id 13909, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 5, length 40
14:35:38.714863 IP (tos 0xc0, ttl 61, id 42690, offset 0, flags [none], proto ICMP (1), length 88)
    10.2.0.5 > 192.168.1.50: ICMP time exceeded in-transit, length 68
IP (tos 0x0, ttl 1, id 13908, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 4, length 40
14:35:38.714863 IP (tos 0x0, ttl 63, id 41579, offset 0, flags [none], proto ICMP (1), length 88)
    10.2.0.143 > 192.168.1.50: ICMP time exceeded in-transit, length 68
IP (tos 0x0, ttl 1, id 13906, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 63919, seq 2, length 40
14:35:38.714864 IP (tos 0x0, ttl 63, id 13910, offset 0, flags [none], proto ICMP (1), length 60)
    10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 6, length 40
14:35:38.714865 IP (tos 0x0, ttl 63, id 13911, offset 0, flags [none], proto ICMP (1), length 60)
    10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 7, length 40
14:35:38.714866 IP (tos 0x0, ttl 63, id 13912, offset 0, flags [none], proto ICMP (1), length 60)
    10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 8, length 40
14:35:38.714867 IP (tos 0x0, ttl 63, id 13913, offset 0, flags [none], proto ICMP (1), length 60)
    10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 9, length 40
14:35:38.716644 IP (tos 0x0, ttl 63, id 13914, offset 0, flags [none], proto ICMP (1), length 60)
    10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 10, length 40
14:35:38.716646 IP (tos 0x0, ttl 63, id 13915, offset 0, flags [none], proto ICMP (1), length 60)
    10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 11, length 40
14:35:38.716647 IP (tos 0x0, ttl 63, id 13916, offset 0, flags [none], proto ICMP (1), length 60)
    10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 12, length 40
14:35:38.716648 IP (tos 0x0, ttl 63, id 13917, offset 0, flags [none], proto ICMP (1), length 60)
    10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 13, length 40
14:35:38.716648 IP (tos 0x0, ttl 63, id 13918, offset 0, flags [none], proto ICMP (1), length 60)
    10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 14, length 40
14:35:38.716649 IP (tos 0x0, ttl 63, id 13919, offset 0, flags [none], proto ICMP (1), length 60)
    10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 15, length 40
14:35:38.716650 IP (tos 0x0, ttl 63, id 13920, offset 0, flags [none], proto ICMP (1), length 60)
    10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 16, length 40
14:35:38.716651 IP (tos 0x0, ttl 63, id 13921, offset 0, flags [none], proto ICMP (1), length 60)
    10.2.0.143 > 192.168.1.50: ICMP echo reply, id 63919, seq 17, length 40



Le ping pong du traceroute est parfaitement normal.

La traceroute cherche tous les routeurs entre l'émetteur et la destination (en augmentant le TTL de 1 à chaque fois), et utilise le ICMP time exceeded pour mesurer la « distance ».

> Demandeur : Je veux PING vers 10.2.0.143 avec un TTL 1
<> 10.2.0.143 « pas moi » (il ne répond pas directement au client) et retourne un ICMP time exceeded (TTL=1)
< Demandeur reçoit le ICMP time exceeded

> Demandeur : Je veux PING vers 10.2.0.143 avec un TTL 2
  > 10.2.0.143 route d'office le paquet vers 10.2.0.4
  > 10.2.0.4 refuse de répondre
* Demandeur ne reçoit rien

> Demandeur : Je veux PING vers 10.2.0.143 avec un TTL 3
  > 10.2.0.143 route d'office le paquet vers 10.2.0.4
  > 10.2.0.4 route d'office le paquet vers 10.2.0.5
<> 10.2.0.5 « pas moi » et retourne un ICMP time exceeded (TTL=3) vers 10.2.0.4
  < 10.2.0.4 fait suivre le ICMP time exceeded vers 10.2.0.143
  < 10.2.0.143 fait suivre le ICMP time exceeded vers le demandeur
< Demandeur reçoit le ICMP time exceeded

> Demandeur : Je veux PING vers 10.2.0.143 avec un TTL 4
  > 10.2.0.143 route d'office le paquet vers 10.2.0.4
  > 10.2.0.4 route d'office le paquet vers 10.2.0.5
  > 10.2.0.5 sait que la route vers 10.2.0.143 passe par 10.2.0.4 et route vers 10.2.0.4
<> 10.2.0.4 « pas moi » et retourne un ICMP time exceeded (TTL=4) vers 10.2.0.5
  < 10.2.0.5 fait suivre le ICMP time exceeded vers 10.2.0.4
  < 10.2.0.4 fait suivre le ICMP time exceeded vers 10.2.0.143
  < 10.2.0.143 fait suivre le ICMP time exceeded vers le demandeur
< Demandeur reçoit le ICMP time exceeded

> Demandeur : Je veux PING vers 10.2.0.143 avec un TTL 5
  > 10.2.0.143 route d'office le paquet vers 10.2.0.4
  > 10.2.0.4 route d'office le paquet vers 10.2.0.5
  > 10.2.0.5 sait que la route vers 10.2.0.143 passe par 10.2.0.4 et route vers 10.2.0.4
  > 10.2.0.4 connaît 10.2.0.143 et route vers 10.2.0.143
<> 10.2.0.143 répond à 10.2.0.4 « c'est moi ! » en retournant un ICMP echo reply
  < 10.2.0.4 fait suivre le ICMP echo reply vers 10.2.0.5
  < 10.2.0.5 fait suivre le ICMP echo reply vers 10.2.0.4
  < 10.2.0.4 fait suivre le ICMP echo reply vers 10.2.0.143
  < 10.2.0.143 fait suivre le ICMP echo reply vers le demandeur
< Demandeur reçoit le ICMP echo reply

Après, les différentes implémentations de traceroute, tracert, mdr et autres n'attendent pas forcément chaque réponse avant de poser la question suivante ; certains le font en parallèle, etc…

Mon point est justement que mtr ne provoque pas cet effet de "ping pong" apparent par rapport à traceroute car, de ce que j'ai pu en voir, il fonctionne en mode "synchrone" (attente de la réponse avant d'envoyer un datagramme avec un TTL incrémenté).

Et donc je ne suis pas d'accord avec ça (ou je n'ai pas compris ce que tu as voulu exprimer) :

mtr interprète les résultats différemment, là ou traceroute n'interprète pas vraiment.
mtr considère le ICMP time exceeded de 10.2.0.143 comme suffisante et ne va pas plus loin.
traceroute attend la réponse ICMP echo reply officielle.

Les paquets pour un ping (ICMP echo request) vers 10.2.0.143 depuis chez toi passent deux fois par 10.2.0.143, car 10.2.0.143 n'est pas autorisé à te répondre directement* (dans la collecte) ; il ne peut répondre qu'à ce qui est passé par 10.2.0.5 (après la collecte donc qui retourne vers 10.2.0.143 par une route autorisée).

* par contre 10.2.0.143 peut retourner directement un ICMP time exceeded.

mtr interprète les résultats différemment, là ou traceroute n'interprète pas vraiment.
mtr considère le ICMP time exceeded de 10.2.0.143 comme suffisante et ne va pas plus loin.
traceroute attend la réponse ICMP echo reply officielle.

Les paquets pour un ping (ICMP echo request) vers 10.2.0.143 depuis chez toi passent deux fois par 10.2.0.143, car 10.2.0.143 n'est pas autorisé à te répondre directement* (dans la collecte) ; il ne peut répondre qu'à ce qui est passé par 10.2.0.5 (après la collecte donc qui retourne vers 10.2.0.143 par une route autorisée).

* par contre 10.2.0.143 peut retourner directement un ICMP time exceeded.

Dans ce cas, explique moi le ttl à 63 dans le paquet retour  :
$ ping -c 1 10.2.0.143
PING 10.2.0.143 (10.2.0.143) 56(84) bytes of data.
64 bytes from 10.2.0.143: icmp_seq=1 ttl=63 time=6.22 ms

--- 10.2.0.143 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 6.224/6.224/6.224/0.000 ms

$ sudo tcpdump -nvvv icmp or host 10.2.0.143
dropped privs to tcpdump
tcpdump: listening on wlp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:12:11.829480 IP (tos 0x0, ttl 64, id 5661, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.1.50 > 10.2.0.143: ICMP echo request, id 3, seq 1, length 64
16:12:11.835664 IP (tos 0x0, ttl 63, id 5661, offset 0, flags [DF], proto ICMP (1), length 84)
    10.2.0.143 > 192.168.1.50: ICMP echo reply, id 3, seq 1, length 64



Merci bolemo pour le détail du traceroute.
Ton explication met bien en évidence le ping-pong.

T'as oublié d'incrémenté le dernier TTL 4->5 . J'ai compris quand même. :-)

mtr interprète les résultats différemment, là ou traceroute n'interprète pas vraiment.
mtr considère le ICMP time exceeded de 10.2.0.143 comme suffisante et ne va pas plus loin.
traceroute attend la réponse ICMP echo reply officielle.

Les paquets pour un ping (ICMP echo request) vers 10.2.0.143 depuis chez toi passent deux fois par 10.2.0.143, car 10.2.0.143 n'est pas autorisé à te répondre directement* (dans la collecte) ; il ne peut répondre qu'à ce qui est passé par 10.2.0.5 (après la collecte donc qui retourne vers 10.2.0.143 par une route autorisée).

* par contre 10.2.0.143 peut retourner directement un ICMP time exceeded.

C'est ce qui m'avait bien perturbé.
143 "ment" quand il s'agit de lui et transmet normalement quand il s'agit des autres.
C'est quand même sioux à comprendre.

Merci bolemo pour le détail du traceroute.
Ton explication met bien en évidence le ping-pong.

T'as oublié d'incrémenté le dernier TTL 4->5 . J'ai compris quand même. :-)
C'est ce qui m'avait bien perturbé.
143 "ment" quand il s'agit de lui et transmet normalement quand il s'agit des autres.
C'est quand même sioux à comprendre.

J'ai corrigé le TTL, merci d'avoir remarqué la coquille.

En fait, (un peu simplifié, mais ça en donne l'idée) aucun appareil dans la collecte (chez Covage) avant 10.2.0.5 (qui est chez K-Net) n'est autorisé à interpréter ou répondre à des sollicitations (à part DHCP, ARP et quelques autres trucs), ils ne doivent que faire suivre vers le point de collecte suivant jusqu'à 10.2.0.5 qui est le seul à décider quoi faire de ces paquets ; quand ce dernier voit que c'est 10.2.0.143, il renvoie les paquets vers ce dernier par un chemin qui autorise les interprétations et réponses.

C'est pareil entre deux clients K-Net qui sont voisins. Si je le ping, mon ping passe obligatoirement par 10.2.0.5.

Pour 143 qui « ment », c'est en fait plus quelque chose comme :
143 ne répond qu'à 10.2.0.4 (qui lui même ne répond qu'à 10.2.0.5). Pour toute demande venant de quelqu'un d'autre, il répond : demandez à 10.2.0.4 (qui lui même va demander à 10.2.0.5).

Je serais un des heureux possesseurs d'un équipement en 00:11:32, je m'inquiéterais un peu, cet OUI appartient à Synology.
Bon, tant qu'il y a cette situation de "spam", il peut y avoir quelques "effets de bord" ... mais ce n'est pas rassurant.

Moi j'aime bien la Freebox (OUI f4:ca:e5)