tracert : passerelle qui n'apparait pas dans le premier hop

[Steph]

Bonjour,
Je ne comprenais pas trop pourquoi la passerelle de mon routeur k-net n'apparaissait pas dans le traceroute et j'ai fait un sujet sur lafibreinfo.

https://lafibre.info/tcpip/tracert-passerelle-qui-napparait-pas-dans-le-premier-hop/

Si vous avez des compléments d'explications sur le principe ou l'architecture Covage74 (ex tutor) K-net, je suis preneur.

Bien cordialement

[Steph]

Bonjour,
Voici ce que donne un traceroute depuis chez moi vers 1.1.1.1.
Ma passerelle de routeur k-box est 185.xxx.xxx.254 et ne répond jamais au ping.

Code Sélectionner Étendre

tracert 1.1.1.1
  1     1 ms     1 ms     1 ms  192.168.1.1 (k-box)
  2     3 ms     3 ms     3 ms  10.2.0.177 (OI Covage local)
  3     *        *        *     Délai d'attente de la demande dépassé. passerelle k-net 185.x.x.254 ?
  4    12 ms    12 ms    12 ms  10.2.0.5
  5    27 ms    17 ms    17 ms  cloudflare.par.franceix.net [37.49.237.49]
  6    14 ms    13 ms    13 ms  one.one.one.one [1.1.1.1]

Tout a été dit dans le fil sur Lafibreinfo ou bien? 

[Vincent O]

Oui, comme ils l'ont dit, un routeur peut avoir plusieurs IPs. La passerelle est forcément le premier hop, donc le routeur de Covage qui porte l'IP de gateway (185.xxx.xxx.254) porte aussi l'IP 10.2.0.177 (probablement son IP de loopback).

[Steph]

Merci Vincent O.
Quel est l'intérêt de ne pas faire répondre au ping l'IP publique de la passerelle? Cela m'avait perturbé lors de mes essais.

Du coup, j'ai fait un traceroute vers la passerelle

Code Sélectionner Étendre

tracert 185.xxx.xxx.254
Détermination de l'itinéraire vers 185.xxx.xxx.254 avec un maximum de 30 sauts.
  1     1 ms     1 ms     1 ms  router.home [192.168.1.1]
  2     3 ms     3 ms     4 ms  10.2.0.177
  3     *        *        *     Délai d'attente de la demande dépassé.
  4    14 ms    12 ms    12 ms  10.2.0.5
  5    25 ms    15 ms    13 ms  172.16.120.95
  6     *        *        *     Délai d'attente de la demande dépassé.
ad vitam...

Pourquoi 10.2.0.177 ne répond-il pas que la route est trouvée?
J'arriverais à comprendre qu'après 10.2.0.177, il n'y ai plus que des "délais dépassés" parce que non réponse au ping de 185.xxx.xxx.254.
Là, ça continue et ça se perd après 3 sauts...?

[Vincent O]

Pourquoi 10.2.0.177 ne répond-il pas que la route est trouvée?

Bonne question : parce qu'il s'en fout de quelle IP vous utilisez comme passerelle.

La chose à savoir, c'est que tous les OI sont arrivés à la conclusion que pour des raisons légales tordues, ils doivent faire remonter tout le traffic jusqu'à la porte de collecte de l'OC. Donc le fameux 10.2.0.177 est configuré pour forwarder tout le traffic  vers notre porte de collecte. Même si la destination est votre voisin, sur le même OLT, même subnet et même VLAN.

Vous pouvez prendre n'importe quelle IP inutilisée qui est dans un préfixe qu'on a assigné pour ce VLAN (et même utilisée, tant que c'est pas un autre client sur le même BNG, le fameux 10.2.0.177) et il forwardera ça.

Code Sélectionner Étendre

# ip -4 r add 1.1.1.1 via 185.251.163.2 dev nas0_1
# traceroute -i nas0_1 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 38 byte packets
1  10.2.0.177 (10.2.0.177)  2.000 ms  3.000 ms  2.000 ms
2  *  *  *
3  10.2.0.5 (10.2.0.5)  13.000 ms  13.000 ms  14.000 ms
4  37.49.237.49 (37.49.237.49)  19.000 ms  13.000 ms  13.000 ms
5  1.1.1.1 (1.1.1.1)  12.000 ms  12.000 ms  12.000 ms

Pour revenir donc au traceroute, le BNG de Covage renvoie tout ça jusqu'à notre porte de collecte (et selon le cas, il peut y avoir 1 ou plusieurs hop pour le faire). 10.2.0.5 c'est enfin chez nous.

Quel est l'intérêt de ne pas faire répondre au ping l'IP publique de la passerelle? Cela m'avait perturbé lors de mes essais.

Comme vous l'avez compris je pense, il n'y a vraiment "personne" qui la porte vraiment. Même si du point de vue de votre routeur, c'est 10.2.0.177. (vous pouvez vérifier la table ARP, c'est le BNG qui sera associé à l'IP de gateway)

Sinon, pour répondre à la question générale, il arrive que certaines réseaux droppent le traffic ICMP echo/reply vers les IP de loopback des routeurs / les IP sur les interfaces / lorsque le TTL = 0, pour limiter le risque de DDoS du routeur.
Il faut savoir que les routeurs de cœurs de réseau utilisent des ASIC spécialisés pour forwarder le traffic entre interface. En général ça ne pose pas de problème pendant les DDoS.
Par contre, ils ont aussi un CPU anémique pour des traitements "de base". Accès SSH et console sont les plus évidents, mais tout ce qui va vers une IP du routeur lui même y passe aussi.
Bref, c'est pas drôle quand un client se fait DDoS, et le routeur où on pourrait mettre une ACL / rate limiting / annonce une blackhole n'est pas joignable parce qu'il se fait aussi DDoS.

[thedark]

Merci à toi Vincent pour cette réponse.
Je comprends mieux les collectes des OI avec les vlans.

[Vincent O]

Merci à toi Vincent pour cette réponse.
Je comprends mieux les collectes des OI avec les vlans.

À noter également que la façon dont c'est implémenté dépend des OI et des RIP.
thedark, toi ta passerelle est vraiment un routeur chez nous.

[Steph]

Merci pour les explications détaillées, Vincent.

[Steph]

Une autre curiosité découverte suite à mes échanges avec le Calvados en panne...
Quand on tracert la passerelle en 10.2.0.177, elle répond mais l'itinéraire n'est pas déterminé pour autant (du au fait qu'elle forward à peu près tout).
Cela fait un ping-pong avec K-net.

Code Sélectionner Étendre

tracert 10.2.0.177

Détermination de l'itinéraire vers labalme.covage [10.2.0.177]
avec un maximum de 30 sauts :

  1    <1 ms    <1 ms    <1 ms  k-box.home [192.168.1.1]
  2     2 ms     2 ms     2 ms  labalme.covage [10.2.0.177]
  3     *        *        *     Délai d'attente de la demande dépassé.
  4    11 ms    12 ms    11 ms  k-net.covage [10.2.0.5]
  5    11 ms    11 ms    11 ms  10.2.0.4
  6    11 ms    11 ms    11 ms  labalme.covage [10.2.0.177]

Itinéraire déterminé.

C'est qui 10.2.0.4 ?

[Minekura]

Cela fait vraiment « j'accepte de te repondre mais d'abord va jusqu'à la collecte knet ».

Je ne savais pas qu'une ip de destination pouvait apparaitre au milieu d'un tracert sans le finaliser pour autant.

[bOLEMO]

Une autre curiosité découverte suite à mes échanges avec le Calvados en panne...
Quand on tracert la passerelle en 10.2.0.177, elle répond mais l'itinéraire n'est pas déterminé pour autant (du au fait qu'elle forward à peu près tout).
Cela fait un ping-pong avec K-net.

Code Sélectionner Étendre

tracert 10.2.0.177

Détermination de l'itinéraire vers labalme.covage [10.2.0.177]
avec un maximum de 30 sauts :

  1    <1 ms    <1 ms    <1 ms  k-box.home [192.168.1.1]
  2     2 ms     2 ms     2 ms  labalme.covage [10.2.0.177]
  3     *        *        *     Délai d'attente de la demande dépassé.
  4    11 ms    12 ms    11 ms  k-net.covage [10.2.0.5]
  5    11 ms    11 ms    11 ms  10.2.0.4
  6    11 ms    11 ms    11 ms  labalme.covage [10.2.0.177]

Itinéraire déterminé.

C'est qui 10.2.0.4 ?

10.2.0.4, c'est le routeur Covage qui livre la collecte K-Net (10.2.0.5)

10.2.0.177 (deuxième hop ici) ne donne probablement pas une réponse satisfaisante pour tracert (pareil avec traceroute) : il ne répond pas aux paquets TCP/UDP/ICMP ECHO_REQUEST envoyés directement depuis chez toi, mais il les fait suivre (après tout c'est un routeur) jusqu'à la collecte K-Net à laquelle 10.2.0.177 accepte de répondre (c'est le ping pong que décrit Vincent O. plus haut).
Cependant 10.2.0.177 retourne des paquets ICMP TTL_EXCEEDED lors d'un tracert vers un hôte vers lequel il route (y compris soi-même via la collecte FAI).

C'est pour cette raison qu'un ping (ICMP ECHO_REQUEST) vers 10.2.0.177 retourne une latence plus longue (ping pong avec la collecte FAI).

[Steph]

Merci Vincent O.
Quel est l'intérêt de ne pas faire répondre au ping l'IP publique de la passerelle? Cela m'avait perturbé lors de mes essais.

Du coup, j'ai fait un traceroute vers la passerelle

Code Sélectionner Étendre

tracert 185.xxx.xxx.254
Détermination de l'itinéraire vers 185.xxx.xxx.254 avec un maximum de 30 sauts.
  1     1 ms     1 ms     1 ms  router.home [192.168.1.1]
  2     3 ms     3 ms     4 ms  10.2.0.177
  3     *        *        *     Délai d'attente de la demande dépassé.
  4    14 ms    12 ms    12 ms  10.2.0.5
  5    25 ms    15 ms    13 ms  172.16.120.95
  6     *        *        *     Délai d'attente de la demande dépassé.
ad vitam...

Pourquoi 10.2.0.177 ne répond-il pas que la route est trouvée?
J'arriverais à comprendre qu'après 10.2.0.177, il n'y ai plus que des "délais dépassés" parce que non réponse au ping de 185.xxx.xxx.254.
Là, ça continue et ça se perd après 3 sauts...?

Il y a eu un changement dans l'infra Covage74-K-net.

Désormais, le tracert vers ma passerelle 185.xxx.xxx.254 va jusqu'au premier routeur qui la porte (10.2.0.177), puis time-out sans que cela termine la recherche.

Code Sélectionner Étendre

tracert 185.xxx.xxx.254

Détermination de l'itinéraire vers 185.xxx.xxx.254 avec un maximum de 30 sauts.

  1     1 ms     1 ms     1 ms  k-box.home [192.168.1.1]
  2     8 ms     3 ms     2 ms  74.covage [10.2.0.177]
  3     *        *        *     Délai d'attente de la demande dépassé.
  4     *        *        *     Délai d'attente de la demande dépassé.
  5     *        *        *     Délai d'attente de la demande dépassé.

[bOLEMO]

Je ne sais pas si c'était différent avant sur Covage Calvados, mais je crois que c'était déjà comme ça (on ne pouvait pas pinger la passerelle) ; en tous cas, maintenant le résultat est pareil que toi :

Code Sélectionner Étendre

root@HERMES:~$ traceroute 2.xxx.xxx.254
traceroute to 2.xxx.xxx.254 (2.xxx.xxx.254), 30 hops max, 38 byte packets
1  10.2.0.211 (10.2.0.211)  2.593 ms  2.655 ms  2.561 ms
2  *  *  *
3  *  *  *
4  *  *  *
etc...

Bien sûr, un arping fonctionne :

Code Sélectionner Étendre

root@HERMES:~$ arping -I brwan 2.xxx.xxx.254
ARPING 2.xxx.xxx.254 from 2.xxx.xxx.xxx brwan
Unicast reply from 2.xxx.xxx.254 [20:e0:9c:53:7a:09] 2.281ms
Unicast reply from 2.xxx.xxx.254 [20:e0:9c:53:7a:09] 2.311ms
Unicast reply from 2.xxx.xxx.254 [20:e0:9c:53:7a:09] 2.312ms

Tiens, d'ailleurs, pourquoi ne pas préciser la MAC des passerelles dans ton fil de discussion sur les passerelles Covage (Tour de France des adresses de collecte de Covage) ?
La MAC de ma passerelle (20:e0:9c:53:7a:09) est la même que celle du serveur/relais DHCP v4 et v6 de mon arbre GPON, donc j'imagine la MAC de la passerelle 10.2.0.211.

Donc passerelle Covage Calvados :
IPv4 10.2.0.211
IPv6 2a03:4980:0:2::211 (link local fe80::22e0:9cff:fe53:7801, mais je ne sais pas s'il dépend se la passerelle ou de l'OLT).
MAC 20:e0:9c:53:7a:09

[Steph]

Cela a un intérêt de faire la table MAC?

Par contre, je ne vois pas comment tu sais que le DHCP relay a la même mac que la passerelle?
Les trames entrantes que j'ai regardées avec Wireshark, ont toutes comme addr.src la mac de ma passerelle, ce qui est logique, non?

J'ai fait un tracert vers le DHCP relay de Covage et j'ai noté que 10.2.0.4 qui d'habitude ne répond jamais pour les trames montantes répond si la cible est le DHCP relay.  10.2.0.4 répond pour les trames descendantes.

Depuis l'extérieur de Covage, 10.2.0.4 et 10.2.05 ne répondent jamais.

[bOLEMO]

Cela a un intérêt de faire la table MAC?

Par contre, je ne vois pas comment tu sais que le DHCP relay a la même mac que la passerelle?
Les trames entrantes que j'ai regardées avec Wireshark, ont toutes comme addr.src la mac de ma passerelle, ce qui est logique, non?

J'ai fait un tracert vers le DHCP relay de Covage et j'ai noté que 10.2.0.4 qui d'habitude ne répond jamais pour les trames montantes répond si la cible est le DHCP relay.  10.2.0.4 répond pour les trames descendantes.

Depuis l'extérieur de Covage, 10.2.0.4 et 10.2.05 ne répondent jamais.

Ce serait inquiétant si 10.2.0.XX répondait de l'extérieur. Ces IP sont interdites sur internet. La boucle Covage est un grand réseau interne.

Pour la MAC, c'est informatif, comme les adresses IP, qui n'ont pas besoin d'être connues pour configurer du matériel perso. Ça peut aider pour des diagnostiques, et aussi indique la marque de la passerelle 
Bref, plus d'info pour nous les geeks curieux de comprendre et connaître l'infrastructure de notre OI.

Pour l'IP du relais DHCP, je ne sais plus comment j'ai déduit cela ; peut-être parce que le RA IPv6 provient de la même MAC que la passerelle.
La passerelle est probablement constituée de plusieurs appareils physiques.