Auteur Sujet: [SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6  (Lu 40269 fois)

0 Membres et 1 Invité sur ce sujet

Steph

  • Abonné K-Net
  • *
  • Messages: 7 689
  • La Balme de Sillingy 74
    • Uptime K-net
[EN COURS] spam DHCPv6 dans la collecte K-Net Covage 14 & 91 (ex-Tutor)
« Réponse #72 le: 04 mai 2022 à 17:09:27 »
Pour comprendre en faisant, j'ai fais les ping en incrémentant le TTL i

Je crois que je comprends tout sauf peut-être la signification du TTL 63 dans la réponse ok à 6 coups.

ping -n 1 -i 1 10.2.0.178 // la collecte locale
Réponse de 192.168.1.1 : Durée de vie TTL expirée lors du transit.

ping -n 1 -i 2 10.2.0.178
Réponse de 10.2.0.178 : Durée de vie TTL expirée lors du transit.
Répond en mentant...

ping -n 1 -i 3 10.2.0.178
Délai d’attente de la demande dépassé.
10.2.0.4 ne répond pas

ping -n 1 -i 4 10.2.0.178
Réponse de 10.2.0.5 : Durée de vie TTL expirée lors du transit.

ping -n 1 -i 5 10.2.0.178
Réponse de 10.2.0.4 : Durée de vie TTL expirée lors du transit.
Répond à 10.2.0.5

ping -n 1 -i 6 10.2.0.178
Réponse de 10.2.0.178 : octets=32 temps=15 ms TTL=63


bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 624
  • Grandcamp Maisy (14)
[EN COURS] spam DHCPv6 dans la collecte K-Net Covage 14 & 91 (ex-Tutor)
« Réponse #73 le: 04 mai 2022 à 17:27:37 »
@Steph : oui, c'est cohérent.

Pour le ttl, j'ai aussi 64 depuis mon routeur vers 10.2.0.211…  ???
Et 63 pour 10.2.0.4 et 62 pour 10.2.0.5

Si je me ping moi-même, j'ai 64 (comme pour 10.2.0.211)

Il faut en conclure que le TTL est calculé différemment, et ne reflète pas le nombre de hops empruntés, mais la distance en hops depuis l'hôte (peut être mesuré en inverse au moment du retour des paquets).


Sinon, des mesures traceroute depuis chez moi :

root@HERMES:~$ traceroute -q1 10.2.0.143
traceroute to 10.2.0.143 (10.2.0.143), 30 hops max, 38 byte packets
 1  10.2.0.211 (10.2.0.211)  2.656 ms
 2  *
 3  10.2.0.5 (10.2.0.5)  6.904 ms
 4  10.2.0.4 (10.2.0.4)  6.935 ms
 5  10.2.0.143 (10.2.0.143)  8.404 ms


root@HERMES:~$ traceroute -q1 10.2.0.178
traceroute to 10.2.0.178 (10.2.0.178), 30 hops max, 38 byte packets
 1  *
 2  *
 3  10.2.0.5 (10.2.0.5)  6.779 ms
 4  10.2.0.4 (10.2.0.4)  7.092 ms
 5  10.2.0.178 (10.2.0.178)  16.120 ms

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 624
  • Grandcamp Maisy (14)
[EN COURS] spam DHCPv6 dans la collecte K-Net Covage 14 & 91 (ex-Tutor)
« Réponse #74 le: 05 mai 2022 à 01:32:31 »
Alors ce soir, toujours le spam DHCPv6, mais les fuites APIPA de K-Box ne sont plus là.

En revanche, les fuites mDNS se sont multipliées, c'est un festival, surtout depuis des appareils non K-Box (dont une Freebox)…


pju91

  • Abonné Free fibre
  • *
  • Messages: 863
  • 91
[EN COURS] spam DHCPv6 dans la collecte K-Net Covage 14 & 91 (ex-Tutor)
« Réponse #75 le: 05 mai 2022 à 09:00:30 »
@Steph : oui, c'est cohérent.

Pour le ttl, j'ai aussi 64 depuis mon routeur vers 10.2.0.211…  ???
Et 63 pour 10.2.0.4 et 62 pour 10.2.0.5

Si je me ping moi-même, j'ai 64 (comme pour 10.2.0.211)

Il faut en conclure que le TTL est calculé différemment, et ne reflète pas le nombre de hops empruntés, mais la distance en hops depuis l'hôte (peut être mesuré en inverse au moment du retour des paquets).
Je continue à penser que l'explication est beaucoup plus simple (mais je ne peux pas le "démontrer"):
les paquets retour en provenance du routeur (10.2.0.143 dans mon cas) sont générés avec un TTL à 64 et reviennent directement à notre LAN, traversant notre routeur personnel (box dans mon cas), d'où un TTL à 63 à l'arrivée.
Sur l'exemple ci-dessous, on observe le même TTL dans le paquet en provenance de 10.2.0.143, lorsque le paquet aller a un TTL de 2 (TTL Exceeded in transit) et un TTL de 6 (Echo Reply).
En revanche, les ping avec TTL croissants de Steph (ou ici) le montrent, la route aller passe par .5 et .4

$ for ttl in {2..6}; do sudo nping -c 1 --icmp --ttl $ttl 10.2.0.143; done

Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0155s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=63024 seq=1] IP [ttl=2 id=63423 iplen=28 ]
RCVD (0.0199s) ICMP [10.2.0.143 > 192.168.1.50 TTL=0 during transit (type=11/code=0) ] IP [ttl=63 id=37165 iplen=56 ]
 
Max rtt: 4.278ms | Min rtt: 4.278ms | Avg rtt: 4.278ms
Raw packets sent: 1 (28B) | Rcvd: 1 (56B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.04 seconds

Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0182s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=62061 seq=1] IP [ttl=3 id=6029 iplen=28 ]
 
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 1 (28B) | Rcvd: 0 (0B) | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.04 seconds

Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0178s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=47221 seq=1] IP [ttl=4 id=43852 iplen=28 ]
RCVD (0.0235s) ICMP [10.2.0.5 > 192.168.1.50 TTL=0 during transit (type=11/code=0) ] IP [ttl=61 id=18562 iplen=56 ]
 
Max rtt: 5.649ms | Min rtt: 5.649ms | Avg rtt: 5.649ms
Raw packets sent: 1 (28B) | Rcvd: 1 (56B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.03 seconds

Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0130s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=22923 seq=1] IP [ttl=5 id=12429 iplen=28 ]
RCVD (0.0194s) ICMP [10.2.0.4 > 192.168.1.50 TTL=0 during transit (type=11/code=0) ] IP [ttl=62 id=40365 iplen=56 ]
 
Max rtt: 6.319ms | Min rtt: 6.319ms | Avg rtt: 6.319ms
Raw packets sent: 1 (28B) | Rcvd: 1 (56B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.03 seconds

Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0153s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=7713 seq=1] IP [ttl=6 id=58688 iplen=28 ]
RCVD (0.0209s) ICMP [10.2.0.143 > 192.168.1.50 Echo reply (type=0/code=0) id=7713 seq=1] IP [ttl=63 id=58688 iplen=28 ]
 
Max rtt: 5.562ms | Min rtt: 5.562ms | Avg rtt: 5.562ms
Raw packets sent: 1 (28B) | Rcvd: 1 (46B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.03 seconds


bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 624
  • Grandcamp Maisy (14)
[EN COURS] spam DHCPv6 dans la collecte K-Net Covage 14 & 91 (ex-Tutor)
« Réponse #76 le: 05 mai 2022 à 11:51:11 »
Je continue à penser que l'explication est beaucoup plus simple (mais je ne peux pas le "démontrer"):
les paquets retour en provenance du routeur (10.2.0.143 dans mon cas) sont générés avec un TTL à 64 et reviennent directement à notre LAN, traversant notre routeur personnel (box dans mon cas), d'où un TTL à 63 à l'arrivée.
Sur l'exemple ci-dessous, on observe le même TTL dans le paquet en provenance de 10.2.0.143, lorsque le paquet aller a un TTL de 2 (TTL Exceeded in transit) et un TTL de 6 (Echo Reply).
En revanche, les ping avec TTL croissants de Steph (ou ici) le montrent, la route aller passe par .5 et .4

$ for ttl in {2..6}; do sudo nping -c 1 --icmp --ttl $ttl 10.2.0.143; done

Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0155s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=63024 seq=1] IP [ttl=2 id=63423 iplen=28 ]
RCVD (0.0199s) ICMP [10.2.0.143 > 192.168.1.50 TTL=0 during transit (type=11/code=0) ] IP [ttl=63 id=37165 iplen=56 ]
 
Max rtt: 4.278ms | Min rtt: 4.278ms | Avg rtt: 4.278ms
Raw packets sent: 1 (28B) | Rcvd: 1 (56B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.04 seconds

Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0182s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=62061 seq=1] IP [ttl=3 id=6029 iplen=28 ]
 
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 1 (28B) | Rcvd: 0 (0B) | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.04 seconds

Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0178s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=47221 seq=1] IP [ttl=4 id=43852 iplen=28 ]
RCVD (0.0235s) ICMP [10.2.0.5 > 192.168.1.50 TTL=0 during transit (type=11/code=0) ] IP [ttl=61 id=18562 iplen=56 ]
 
Max rtt: 5.649ms | Min rtt: 5.649ms | Avg rtt: 5.649ms
Raw packets sent: 1 (28B) | Rcvd: 1 (56B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.03 seconds

Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0130s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=22923 seq=1] IP [ttl=5 id=12429 iplen=28 ]
RCVD (0.0194s) ICMP [10.2.0.4 > 192.168.1.50 TTL=0 during transit (type=11/code=0) ] IP [ttl=62 id=40365 iplen=56 ]
 
Max rtt: 6.319ms | Min rtt: 6.319ms | Avg rtt: 6.319ms
Raw packets sent: 1 (28B) | Rcvd: 1 (56B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.03 seconds

Starting Nping 0.7.92 ( https://nmap.org/nping ) at 2022-05-05 08:54 CEST
SENT (0.0153s) ICMP [192.168.1.50 > 10.2.0.143 Echo request (type=8/code=0) id=7713 seq=1] IP [ttl=6 id=58688 iplen=28 ]
RCVD (0.0209s) ICMP [10.2.0.143 > 192.168.1.50 Echo reply (type=0/code=0) id=7713 seq=1] IP [ttl=63 id=58688 iplen=28 ]
 
Max rtt: 5.562ms | Min rtt: 5.562ms | Avg rtt: 5.562ms
Raw packets sent: 1 (28B) | Rcvd: 1 (46B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.03 seconds


Ça tient la route (c'est le cas de le dire  :D)
Ce doit être ça, c'est l'explication la plus simple.

10.2.0.143 et 10.2.0.4 savent donc comment envoyer la réponse directement sans reprendre le chemin inverse.
En revanche, il ne répondent qu'au questions qui passent pas 10.2.0.5.
Et la latence incluant le temps que la question leur arrive, c'est cohérent.

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 624
  • Grandcamp Maisy (14)
[TERMINÉ] spam DHCPv6 dans la collecte K-Net Covage 14 & 91 (ex-Tutor)
« Réponse #77 le: 05 mai 2022 à 12:31:29 »
Au fait : 9h53, fin de l'incident DHCPv6  :)

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 624
  • Grandcamp Maisy (14)
[TERMINÉ] spam DHCPv6 dans la collecte K-Net Covage 14 & 91 (ex-Tutor)
« Réponse #78 le: 05 mai 2022 à 13:09:36 »
Voilà donc l'explication tenant compte de la remarque de pju91 :
En supposant que le demandeur est directement derrière l'ONT (depuis le routeur ou un PC sur l'ONT)
Depuis un autre appareil sur le LAN après la Box ou le routeur, le TTL doit donc être de +1 pour passer la Box ou le routeur qui mange un hop


> Demandeur envoie un ICMP echo request vers 10.2.0.143 avec un TTL 1
>< 10.2.0.143 TTL=0 veut faire suivre d'office l'ICMP echo request à 10.2.0.4 mais le TTL l'en empêche et retourne un ICMP time exceeded
< Demandeur reçoit l'ICMP time exceeded

> Demandeur envoie un ICMP echo request 10.2.0.143 avec un TTL 2
> 10.2.0.143 TTL=1 fait suivre d'office l'ICMP echo request à 10.2.0.4
> 10.2.0.4 TTL=0 veut faire suivre d'office l'ICMP echo request à 10.2.0.5 mais le TTL l'en empêche. Il ne retourne rien (ou retourne peut-être un ICMP time exceeded vers 10.2.0.143, mais en ce cas, ce dernier ne transmet pas au Demandeur)
* Demandeur ne reçoit rien

> Demandeur envoie un ICMP echo request 10.2.0.143 avec un TTL 3
> 10.2.0.143 TTL=2 fait suivre d'office l'ICMP echo request à 10.2.0.4
> 10.2.0.4 TTL=1 fait suivre d'office l'ICMP echo request à 10.2.0.5
>< 10.2.0.5 TTL=0 reçoit l'ICMP echo request et sait que la route vers 10.2.0.143 passe par 10.2.0.4 et veut le faire suivre, mais le TTL l'en empêche et retourne un ICMP time exceeded
< 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 envoie un ICMP echo request 10.2.0.143 avec un TTL 4
> 10.2.0.143 TTL=3 fait suivre d'office l'ICMP echo request à 10.2.0.4
> 10.2.0.4 TTL=2 fait suivre d'office l'ICMP echo request à 10.2.0.5
> 10.2.0.5 TTL=1 reçoit l'ICMP echo request et sait que la route vers 10.2.0.143 passe par 10.2.0.4 et le fait donc suivre
>< 10.2.0.4 TTL=0 reçoit l'ICMP echo request et veut le faire suivre à 10.2.0.143 mais le TTL l'en empêche et retourne un ICMP time exceeded
< 10.2.0.143 fait suivre l'ICMP time exceeded vers le demandeur
< Demandeur reçoit le ICMP time exceeded

> Demandeur envoie un ICMP echo request 10.2.0.143 avec un TTL 5
> 10.2.0.143 TTL=4 fait suivre d'office l'ICMP echo request à 10.2.0.4
> 10.2.0.4 TTL=3 fait suivre d'office l'ICMP echo request à 10.2.0.5
> 10.2.0.5 TTL=2 reçoit l'ICMP echo request et sait que la route vers 10.2.0.143 passe par 10.2.0.4 et le fait donc suivre
> 10.2.0.4 TTL=1 reçoit l'ICMP echo request et le fait suivre vers 10.2.0.143 qu'il connaît
>< 10.2.0.143 reçoit l'ICMP echo request et répond en retournant un ICMP echo reply au demandeur
< Demandeur reçoit le ICMP echo reply
« Modifié: 05 mai 2022 à 14:54:10 par bolemo »

pju91

  • Abonné Free fibre
  • *
  • Messages: 863
  • 91
[TERMINÉ] spam DHCPv6 dans la collecte K-Net Covage 14 & 91 (ex-Tutor)
« Réponse #79 le: 05 mai 2022 à 13:36:02 »
C'est presque ça ...
MAIS : ma boucle sur les TTL croissants est entre 2 et 6.
Car, avec un TTL à 1, ça s'arrête à ma box, puisque j'ai lancé à partir d'un PC derrière la box, pas à partir de la box.
Le paquet avec TTL 1  expire donc sur ma box, ça n'avait pas d'intérêt de le montrer.
Je te laisse "éditer" ton message pour la postérité

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 624
  • Grandcamp Maisy (14)
[TERMINÉ] spam DHCPv6 dans la collecte K-Net Covage 14 & 91 (ex-Tutor)
« Réponse #80 le: 05 mai 2022 à 14:10:42 »
C'est presque ça ...
MAIS : ma boucle sur les TTL croissants est entre 2 et 6.
Car, avec un TTL à 1, ça s'arrête à ma box, puisque j'ai lancé à partir d'un PC derrière la box, pas à partir de la box.
Le paquet avec TTL 1  expire donc sur ma box, ça n'avait pas d'intérêt de le montrer.
Je te laisse "éditer" ton message pour la postérité

Oui, mon exemple prend en compte que le demandeur est directement après l'ONT (ce qui est bien mon cas quand je fais ping ou traceroute depuis le routeur), pour ne montrer que ce qu'il se passe dans la boucle.
Ajouter la structure interne du LAN compliquerait la lecture je pense…

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 624
  • Grandcamp Maisy (14)
[TERMINÉ] spam DHCPv6 dans la collecte K-Net Covage 14 & 91 (ex-Tutor)
« Réponse #81 le: 05 mai 2022 à 15:13:20 »
Voilà donc l'explication tenant compte de la remarque de pju91 :
En supposant que le demandeur est directement derrière l'ONT (depuis le routeur ou un PC sur l'ONT)
Depuis un autre appareil sur le LAN après la Box ou le routeur, le TTL doit donc être de +1 pour passer la Box ou le routeur qui mange un hop


> Demandeur envoie un ICMP echo request vers 10.2.0.143 avec un TTL 1
>< 10.2.0.143 TTL=0 veut faire suivre d'office l'ICMP echo request à 10.2.0.4 mais le TTL l'en empêche et retourne un ICMP time exceeded
< Demandeur reçoit l'ICMP time exceeded

> Demandeur envoie un ICMP echo request 10.2.0.143 avec un TTL 2
> 10.2.0.143 TTL=1 fait suivre d'office l'ICMP echo request à 10.2.0.4
> 10.2.0.4 TTL=0 veut faire suivre d'office l'ICMP echo request à 10.2.0.5 mais le TTL l'en empêche. Il ne retourne rien (ou retourne peut-être un ICMP time exceeded vers 10.2.0.143, mais en ce cas, ce dernier ne transmet pas au Demandeur)
* Demandeur ne reçoit rien

> Demandeur envoie un ICMP echo request 10.2.0.143 avec un TTL 3
> 10.2.0.143 TTL=2 fait suivre d'office l'ICMP echo request à 10.2.0.4
> 10.2.0.4 TTL=1 fait suivre d'office l'ICMP echo request à 10.2.0.5
>< 10.2.0.5 TTL=0 reçoit l'ICMP echo request et sait que la route vers 10.2.0.143 passe par 10.2.0.4 et veut le faire suivre, mais le TTL l'en empêche et retourne un ICMP time exceeded
< 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 envoie un ICMP echo request 10.2.0.143 avec un TTL 4
> 10.2.0.143 TTL=3 fait suivre d'office l'ICMP echo request à 10.2.0.4
> 10.2.0.4 TTL=2 fait suivre d'office l'ICMP echo request à 10.2.0.5
> 10.2.0.5 TTL=1 reçoit l'ICMP echo request et sait que la route vers 10.2.0.143 passe par 10.2.0.4 et le fait donc suivre
>< 10.2.0.4 TTL=0 reçoit l'ICMP echo request et veut le faire suivre à 10.2.0.143 mais le TTL l'en empêche et retourne un ICMP time exceeded
< 10.2.0.143 fait suivre l'ICMP time exceeded vers le demandeur
< Demandeur reçoit le ICMP time exceeded

> Demandeur envoie un ICMP echo request 10.2.0.143 avec un TTL 5
> 10.2.0.143 TTL=4 fait suivre d'office l'ICMP echo request à 10.2.0.4
> 10.2.0.4 TTL=3 fait suivre d'office l'ICMP echo request à 10.2.0.5
> 10.2.0.5 TTL=2 reçoit l'ICMP echo request et sait que la route vers 10.2.0.143 passe par 10.2.0.4 et le fait donc suivre
> 10.2.0.4 TTL=1 reçoit l'ICMP echo request et le fait suivre vers 10.2.0.143 qu'il connaît
>< 10.2.0.143 reçoit l'ICMP echo request et répond en retournant un ICMP echo reply au demandeur
< Demandeur reçoit le ICMP echo reply

Discussion sur cela en regardant les résultats du traceroute (dans mon cas, c'est 10.2.0.211 et non 10.2.0.143, mais le reste est identique) :
root@HERMES:~$ traceroute -q1 10.2.0.211
traceroute to 10.2.0.211 (10.2.0.211), 30 hops max, 38 byte packets
 1  10.2.0.211 (10.2.0.211)  2.468 ms
 2  *
 3  10.2.0.5 (10.2.0.5)  6.810 ms
 4  10.2.0.4 (10.2.0.4)  6.935 ms
 5  10.2.0.211 (10.2.0.211)  6.966 ms

Le premier hop est à 2,5 ms environ. Cas avec un TTL=1. C'est le temps entre l'émission du ICMP echo request par le demandeur et la réception du ICMP time exceeded
Ici, entre l'émission de la demande et la réception de la réponse (ici time exceeded), on passe par 1 seul routeur.

Le deuxième hop est indéfini. Cas avec un TTL=2. Aucune réponse n'est reçue par le demandeur.

Le troisième hop, quatrième hop et cinquième hop sont les cas avec des TTL de 3, 4 et 5.
Pour les TTL à 3 et 4, c'est le temps entre l'émission du ICMP echo request par le demandeur et la réception du ICMP time exceeded
Pour le TTL à 5, c'est le temps entre l'émission du ICMP echo request par le demandeur et la réception du ICMP echo reply
Il est intéressant de noter que les latences sont à peu près identiques pour ces trois cas de figure à un peu moine de 7 ms ; c'est cohérent, car dans l'explicatif, on voit bien que dans les 3 cas, entre l'émission de la demande et la réception d'une réponse (time exceeded ou reply), on passe dans tous les cas par 5 routeurs (les 5 mêmes), donc les délais dans ces trois cas de figure sont logiquement à peu près les mêmes.

pju91

  • Abonné Free fibre
  • *
  • Messages: 863
  • 91
[TERMINÉ] spam DHCPv6 dans la collecte K-Net Covage 14 & 91 (ex-Tutor)
« Réponse #82 le: 05 mai 2022 à 16:49:09 »
Bravo, tu as bien décortiqué tout ça, ça me paraît très clair. En espérant que ça permettra à d'autres de comprendre comment ça fonctionne.
C'est un peu dommage d'être obligés de faire ce genre de "reverse engineering".
Sans dévoiler de "secret industriel", Covage gagnerait à documenter un peu mieux leur infrastructure ... mais il est vrai que dans certains secteurs dont le tien, ils ne doivent pas en être très fiers.

Concernant le traceroute, j'ai le même genre d'observation que toi (mais du LAN) :
$ traceroute -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  8.663 ms
 2  10.2.0.143  8.599 ms
 3  *
 4  10.2.0.5  8.529 ms
 5  10.2.0.4  8.520 ms
 6  10.2.0.143  8.504 ms

Steph

  • Abonné K-Net
  • *
  • Messages: 7 689
  • La Balme de Sillingy 74
    • Uptime K-net
[TERMINÉ] spam DHCPv6 dans la collecte K-Net Covage 14 & 91 (ex-Tutor)
« Réponse #83 le: 05 mai 2022 à 17:22:01 »
@bolemo
Superbes explications qui closent mon fil : https://lafibre.info/tcpip/tracert-passerelle-qui-napparait-pas-dans-le-premier-hop/msg943976/#msg943976
Il y avait aussi l'équivalent sur CAPS où VincentO avait expliqué des trucs!  :'(