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
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.
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? :)
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).
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
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...?
Citation de: Steph le 14 Décembre 2019 à 15:20:49
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.
# 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 msPour 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.
Citation de: Steph le 14 Décembre 2019 à 15:20:49
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.
Merci à toi Vincent pour cette réponse.
Je comprends mieux les collectes des OI avec les vlans.
Citation de: thedark le 14 Décembre 2019 à 19:01:44
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.
Merci pour les explications détaillées, Vincent.
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.
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 ?
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.
Citation de: Steph le 25 Janvier 2020 à 21:30:37
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.
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).
Citation de: Steph le 14 Décembre 2019 à 15:20:49
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
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.
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é.
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 :
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 :
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
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.
Citation de: Steph le 29 Avril 2021 à 13:46:42
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.
Citation de: bOLEMO le 29 Avril 2021 à 14:17:36
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.
Oui et non, tu peux les utiliser sur un réseau connecté a internet, elles ne seront simplement joignables que depuis ton réseau.
En soi, rien n'interdit de les utiliser :)
Oui, je me suis un peu pris les pieds dans le tapis.
On peut utiliser des adresses privées pour les routeurs sur un réseau connecté a internet (la preuve) mais c'est normal qu'elle ne répondent pas aux ping.
Citation de: bOLEMO le 29 Avril 2021 à 12:28:47
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
Mis à jour sur https://forum.caps.services/index.php/topic,7534.msg95039.html#msg95039
Citation de: Steph le 29 Avril 2021 à 17:03:05
mais c'est normal qu'elle ne répondent pas aux ping.
Pas forcément normal, mais pas choquant non plus :)
Mince alors, il doit encore m'en manquer un morceau...
Un routeur pourrait répondre une adresse privée lors d'un tracert depuis l'extérieur du réseau?
Citation de: Steph le 29 Avril 2021 à 17:55:29
Mince alors, il doit encore m'en manquer un morceau...
Un routeur pourrait répondre une adresse privée lors d'un tracert depuis l'extérieur du réseau?
Tant tu reste en interne oui.
Citation de: thedark le 29 Avril 2021 à 18:01:27
Citation de: Steph le 29 Avril 2021 à 17:55:29
Mince alors, il doit encore m'en manquer un morceau...
Un routeur pourrait répondre une adresse privée lors d'un tracert depuis l'extérieur du réseau?
Tant tu reste en interne oui.
Oui, on est bien d'accord, comme quand je Ping 192.168.XX.XX par exemple en interne. Mais depuis le WAN, bien entendu pas pingable.
Tant qu'on est dans le réseau Covage, on peut voir ces adresses privées, mais pas depuis l'internet après Covage.
Les routeur de la porte entre Covage et K-Net ne doivent pas router ces adresses privées vers K-Net.
Citation de: Steph le 29 Avril 2021 à 17:55:29
Mince alors, il doit encore m'en manquer un morceau...
Un routeur pourrait répondre une adresse privée lors d'un tracert depuis l'extérieur du réseau?
Oui, tu peux même en voir sur internet. C'est juste l'annonce BGP qui est interdite (ce qui fait que si tu envoies un paquet avec une IP Privée en source, tu ne recevras pas la réponse en dehors de ton réseau), mais tout le reste est autorisé.
Citation de: Vincent O le 14 Décembre 2019 à 15:01:19
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).
Donc, si j'ai bien compris, les routeurs de collecte Covage 10.2.0.x portent toutes adresses de passerelles de K-net et des autres FAI?
Citation de: Vincent O le 14 Décembre 2019 à 15:01:19
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).
Je dirais même qu'il pourrait très bien ne pas porter du tout l'IP de loopback, ce n'est pas indispensable en faisant de d'ARPProxy par exemple.