La Fibre
Télécom => Réseau => 
TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: Steph le 21 novembre 2019 à 21:22:37
-
Bonjour,
Je pensais avoir compris le principe de la passerelle IP du temps de l'ADSL et je réalise à l'occasion du passage à la fibre que je n'ai sans doute pas tout compris.
Je ne comprend pas pourquoi le second hop n'est pas la passerelle du routeur?
J'imagine que le hop 3 est la passerelle et qu'elle ne répond pas au ping et tracert?
J'ai l'impression de rater un truc...
Merci pour l'éclairage.
Cordialement.
Edit : J'ai oublié de préciser que je suis sur une offre activée K-net+Covage74. (Si cela peut aider à comprendre ce que je ne comprend pas...)
Edit : Y a-t-il un rapport avec le fait que les @ 10.2.0.0 soient privées?
Config de mon routeur
Adresse privée : 192.168.1.1/24
Adresse publique : x.x.x.y/22
Passerelle : x.x.x.254
tracert 1.1.1.1
1 1 ms 1 ms 1 ms 192.168.1.1 (box)
2 3 ms 3 ms 3 ms 10.2.0.177
3 * * * Délai d’attente de la demande dépassé.
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]
Itinéraire déterminé.
-
Je n'ai pas compris quelle est la question.
Les périphériques affichés dans un traceroute sont des routeurs (périphérique de couche 3 qui interconnecte 2 réseaux IP).
Donc le 2ème saut indiqué est un routeur, qui semble effectivement très local vu le délais de réponse (un routeur présent dans ta ville, ou peut-être département...).
Certains opérateurs peuvent utiliser des IP privées pour les routeurs à l'intérieur de leur réseau, il me semble que ce n'est pas considéré comme une "bonne pratique" mais bon ça fonctionne, et avec la pénurie d'IPv4 ce n'est pas plus mal.
Le 3ème saut ne répond effectivement pas aux paquets ICMP.
Il faut faire attention que les traceroute ne peuvent faire apparaitre que les périphériques de couche 3 les plus "haut niveau" dans la pile réseau, donc dans le cas d'une tunnelisation quelque part, une ou plusieurs couches 3 peuvent ne pas apparaitre, c'est normal. (Free fait du tunnel systématique vers Paris en IPv4 sur ses nouvelles infras, donc le 2ème saut dans le traceroute, peu importe la localisation du client est localisée à Paris, même si plusieurs routeurs sont traversés localement bien avant Paris !).
-
Merci pour les informations.
Ce qui me pose problème est que ce n'est pas la passerelle de ma box qui répondent au deuxième saut. Au boulot et avec mon ancien ADSL, c'est toujours le cas.
Le saut 3 qui ne répond pas pourrait être la passerelle de la box ? (passerelle qui ne répond pas au ping).
Cela ferait donc :
tracert 1.1.1.1
1 1 ms 1 ms 1 ms 192.168.1.1 (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 FAI x.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]
J'avais en tête que la passerelle apparaissait toujours dans les traceroutes, ce qui n'est visiblement pas le cas.
Cordialement.
-
Merci pour les informations.
Ce qui me pose problème est que ce n'est pas la passerelle de ma box qui répondent au deuxième saut. Au boulot et avec mon ancien ADSL, c'est toujours le cas.
Le saut 3 qui ne répond pas pourrait être la passerelle de la box ? (passerelle qui ne répond pas au ping).
Cela ferait donc :
tracert 1.1.1.1
1 1 ms 1 ms 1 ms 192.168.1.1 (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 FAI x.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]
J'avais en tête que la passerelle apparaissait toujours dans les traceroutes, ce qui n'est visiblement pas le cas.
Cordialement.
Tu saisis mal le terme "passerelle".
En gros, chaque saut dans ton traceroute (sauf le dernier), ce sont tous des passerelles. En effet, ta passerelle au 1er saut (ta box), elle connait pas la route vers 1.1.1.1, du coup elle va filer ton paquet à sa propre passerelle, soit 10.2.0.177.
Pas de bol, 10.2.0.177 ne connait pas non plus la route vers 1.1.1.1, du coup il va filer ton paquet à sa propre passerelle, soit xxx.xxx.xxx.xxx (une IP qui ping pas, mais qui fait le job, car tu arrives à aller à l'étape d'après).
Par contre, le bestiau en 37.49.237.49, lui il connait une route directe vers 1.1.1.1 et va directement filer le paquet à la machine qui va bien :)
** EDIT
Il faut aussi séparer la notion d'équipement L1/L2/L3 etc
En fibre, la connectivité peut s'arrếter physiquement sur l'OLT, mais la connectivité IP peut être terminée sur un équipement plus loin par exemple.
-
A mon avis la confusion vient peut-être du fait que dans la box, son prochain saut (passerelle) est peut-être désignée avec une autre adresse que "10.2.0.177". C'est possible selon la conception du réseau derrière, un routeur a de toute façon toujours plusieurs adresses IP.
-
Pareil, je ne vois pas le souci, c'est juste une IP privée, ça marche très bien en backbone...
-
En gros, chaque saut dans ton traceroute (sauf le dernier), ce sont tous des passerelles. En effet, ta passerelle au 1er saut (ta box), elle connait pas la route vers 1.1.1.1, du coup elle va filer ton paquet à sa propre passerelle, soit 10.2.0.177.
Ben c'est cela qu'est bizarre pour moi car la passerelle de la box est sensée être un 185.x.x.254 de mon FAI. C'est ce que je vois comme passerelle par défaut quand je connecte un PC directement.
Et malgré la passerelle en 185.x.x.254 de la box, le second hop est en 10.2.0.177
-
Et malgré la passerelle en 185.x.x.254 de la box, le second hop est en 10.2.0.177
Il faut que tu comprennes qu'un routeur a plusieurs interfaces, plusieurs IP.
-
Pas forcément lié Thornill.
On est pas dans un sous réseau classique là, donc la passerelle peut être n'importe quelle IP, on s'en fiche, suffit de faire du routage onlink : On sait que la passerelle est joignable, peu importe le sous-réseau de l'IP dans laquelle on est :)
-
C'est juste que la réponse au ttl a 0 du traceroute ne se fait pas forcement avec l'IP de l'interface (ou une des IP s'il y en a plusieurs) sur laquelle le paquet est arrivé. Ca peut être l'IP loopback par exemple. Certains font ca sur leur routeur pour éviter de divulguer les IP réelles des interfaces et/ou pour identifier plus facilement leurs routeurs (stabilité des IP visibles dans les traceroutes).
-
Ça me rassure, ce n'est pas si simple. Je pense avoir le niveau de base en routage IP. Il faut que je regarde pour routage "onlink" et le fait que la réponse d'un routeur au tracert n'est pas forcément celle avec laquelle il a été atteint.
Merci pour vos réponses.
-
Vincent O m'a fait une réponse détaillée sur CAPS qui m'a permis de mieux comprendre ce qui se passe avec cette première passerelle.
https://forum.caps.services/index.php/topic,7314.msg92746.html#msg92746
-
Bonjour,
Quand je trace route la passerelle en 10.2.0.177, elle répond mais l'itinéraire n'est pas déterminer pour autant (du au fait qu'elle forwarde à peu près tout).
Cela fait un ping-pong avec K-net.
tracert 10.2.0.177
Détermination de l'itinéraire vers [10.2.0.177]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms [192.168.1.1]
2 2 ms 2 ms 2 ms [10.2.0.177]
3 * * * Délai d'attente de la demande dépassé.
4 11 ms 12 ms 11 ms [10.2.0.5]
5 11 ms 11 ms 11 ms 10.2.0.4
6 11 ms 11 ms 11 ms [10.2.0.177]
Itinéraire déterminé.Comme dit Minekura (https://forum.caps.services/index.php/topic,7314.msg94551.html#msg94551)
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.
C'est un cas qui se rencontre souvent?
Cordialement.
-
Bonjour,
disons que faire un traceroute sur une ip privée sans vraiment connaitre le réseau c'est pas forcément évident à interpréter ..
-
En tout cas, ça m'a fait réfléchir. :)
Je n'avais jamais rencontrer ce cas!
-
Pour essayer d'obtenir l'IP du 3ème hop, tu peux aussi essayer un traceroute TCP.
-
J'ai essayé, c'est muet ;).
C'était surtout le fait que l'IP privée de la passerelle apparaisse une fois au début et une fois à la fin du traceroute qui m’intriguait. Ainsi que le fait que mon routeur avait comme passerelle une IP publique qui ne répondait pas mais fonctionnait.
-
C'est juste de l'IP Unnumbered et de l'ARP Proxy :)
-
Merci Hugues. Je retourne me cultiver avec ces indications.
-
tracert 10.2.0.177
Détermination de l'itinéraire vers [10.2.0.177]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms [192.168.1.1]
2 2 ms 2 ms 2 ms [10.2.0.177]
3 * * * Délai d'attente de la demande dépassé.
4 11 ms 12 ms 11 ms [10.2.0.5]
5 11 ms 11 ms 11 ms 10.2.0.4
6 11 ms 11 ms 11 ms [10.2.0.177]
Malgré les indications d'Hugues, je n'ai pas réussi à comprendre pourquoi le tracert ne s'arrêtait pas dès sa cible atteinte la première fois.
Une petite piste?
-
Pourquoi il s'arrêterait ? Qu'est-ce qui fait arrêter un traceroute ?
-
Surtout il faut bien comprendre que le traceroute est à l’entière merci des différents réseaux qu'il traverse.
Un réseau peut décider de ne pas répondre, de filtrer la demande, de modifier la réponse (volontairement (les traceroutes qui se finissent au second saut pour toutes les destinations, pare-feu qui ne décrémente pas le TTL pour être "furtif") ou involontairement (MPLS avec ICMP tunneling)).
-
Pourquoi il s'arrêterait ? Qu'est-ce qui fait arrêter un traceroute ?
De ce que je comprends, la réponse de 177 au premier ping avec TTL=1 n'envoie pas le TTL exceeded qui terminerait le traceroute? Il répond quand même mais sans décrémenter le TTL?
Du coup, le traceroute incrémente le TTL pour trouver le saut suivant, jusqu'à retomber sur le 177 qui pingué du coté FAI répond normalement et envoie le TTL exeeded?
Edit :
D'ailleurs, je constate que le ping du 177 est à 11 ms (donc passage par K-net à Paris) et que le premier hop du tracert sur 177 est à 2ms (local, direct), puis 11ms comme pour le ping.
-
Ce que j'ai raconté avant ne doit pas être trop faux. ;)
Encore un truc qui m'échappe avec les traceroutes.
Sur la bizarrerie de ma passerelle qui oblige à passer par le FAI, selon l'outil utilisé, je n'ai pas les mêmes réponses.
tracert de win10 : aller retour
tracert 10.2.0.177
Détermination de l'itinéraire vers [10.2.0.177]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms [192.168.1.1]
2 2 ms 2 ms 2 ms [10.2.0.177]
3 * * * Délai d'attente de la demande dépassé.
4 11 ms 12 ms 11 ms [10.2.0.5]
5 11 ms 11 ms 11 ms 10.2.0.4
6 11 ms 11 ms 11 ms [10.2.0.177]
WinMTR v0.92 : Pas d'aller retour
WinMTR v0.92
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| k-box.home - 0 | 6 | 6 | 3 | 4 | 5 | 5 |
| 10.2.0.177 - 0 | 6 | 6 | 4 | 5 | 7 | 4 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
-
Ca marche "mieux" de chez moi :
$ traceroute 10.2.0.177
traceroute to 10.2.0.177 (10.2.0.177), 30 hops max, 60 byte packets
1 box (192.168.1.1) 7.228 ms 7.142 ms 7.110 ms
2 10.2.0.143 (10.2.0.143) 7.096 ms 7.067 ms 7.040 ms
3 * * *
4 10.2.0.5 (10.2.0.5) 6.944 ms 6.932 ms 8.403 ms
5 10.2.0.4 (10.2.0.4) 6.915 ms 8.388 ms 8.376 ms
6 10.2.0.177 (10.2.0.177) 32.156 ms 29.970 ms 29.938 ms
$ mtr -r -c 4 10.2.0.177
Start: 2022-04-27T14:53:45+0200
HOST: fedora Loss% Snt Last Avg Best Wrst StDev
1.|-- box 0.0% 4 3.5 3.4 3.3 3.5 0.1
2.|-- 10.2.0.143 0.0% 4 5.4 5.2 4.9 5.4 0.2
3.|-- ??? 100.0 4 0.0 0.0 0.0 0.0 0.0
4.|-- 10.2.0.5 0.0% 4 6.0 5.8 5.4 6.1 0.3
5.|-- 10.2.0.4 0.0% 4 6.4 6.4 5.9 7.2 0.5
6.|-- 10.2.0.177 0.0% 4 29.4 29.3 29.1 29.5 0.2
-
Ca marche "mieux" de chez moi :
C'est parce que le 10.2.0.177 n'est pas ta passerelle (c'était la mienne).
Essaie avec 10.2.0.143 et tu devrais voir l'aller retour.
Le saut 3 est probablement 10.2.0.4 qui ne répond que dans un sens.