Ce n'est pas un probleme lie directement a linux mais bon ... si quelqu un a un semblant d'explication je lui serai eternellement reconnaissant :)
Je suis actuellement en chine et je dois me connecter a un site francais. gros problemes, vitesse mauvaise, timeout a repetition ... bref pas cool. Petit diagnostic, je fais un traceroute vers le site en question et la surprise , les temps sont vraiment loin d'etre croissant. Comment expliquer ca ??
2 218.65.208.177 (218.65.208.177) 12.471 ms 11.777 ms 12.568 ms
3 202.103.201.57 (202.103.201.57) 13.514 ms 16.194 ms 13.110 ms
4 202.103.201.9 (202.103.201.9) 12.026 ms 12.302 ms 13.037 ms
5 202.97.21.129 (202.97.21.129) 16.762 ms 15.428 ms 15.006 ms
6 202.97.40.229 (202.97.40.229) 23.399 ms 24.683 ms 24.624 ms
7 202.97.33.150 (202.97.33.150) 24.832 ms 24.268 ms 27.053 ms
8 202.97.51.34 (202.97.51.34) 222.232 ms 243.256 ms *
9 202.97.49.5 (202.97.49.5) 387.694 ms 375.694 ms 395.659 ms
10 202.97.48.82 (202.97.48.82) 223.706 ms * 225.176 ms
11 P14-0.SJOCR1.San-jose.opentransit.net (193.251.243.122) 224.441 ms 218.966 ms 216.534 ms
12 P14-0.NYKCR2.New-york.opentransit.net (193.251.242.1) 291.726 ms 417.811 ms 337.010 ms
13 P5-0.AUVCR2.Aubervilliers.opentransit.net (193.251.243.233) 435.633 ms 457.456 ms 448.638 ms
14 P3-0.PASCR1.Pastourelle.opentransit.net (193.251.128.118) 378.430 ms 389.700 ms 402.308 ms
15 pos15-0.ntsta202.Paris.francetelecom.net (193.251.126.57) 383.603 ms * 388.792 ms
16 pos0-1-2-0.nrpoi202.Poitiers.francetelecom.net (193.252.103.45) 444.716 ms 464.415 ms 465.631 ms
17 pos9-0.ncbor202.Bordeaux.francetelecom.net (193.252.100.113) 647.730 ms 646.447 ms 632.185 ms
18 193.253.14.54 (193.253.14.54) 652.893 ms 618.857 ms 628.729 ms
19 81.52.12.86 (81.52.12.86) 440.997 ms * 405.172 ms
20 81.54.17.46 (81.54.17.46) 434.359 ms 451.801 ms 444.199 ms
PS: clavier qwerty oblige desole pour les accents
# Besoins de plus de données, de plus de pings et d'autres traceroutes
Posté par RuleZ . Évalué à 8.
Pour chaque routeur, la décision de routage est arbitraire selon ses données et sensible à sa variante algorithmique. L'objectif ce n'est pas de simplement prendre le chemin le plus court, mais surtout d'arriver à destination (on peut parfois voir des paquets faire 2 fois le tour du monde)
Bref, le chemin qui sera pris par le paquet doit être vu comme une succession de décisions de routage, routeur par routeur, mais surtout pas en globalité. Chaque routeur ne pourra choisir que parmis les autres routeurs auquels il est directement connecté (ses moyens physique), et ce en fonction de la destination à atteindre (l'objectif), "il passe le paquet au voisin qu'il juge, selon ses propres critères, comme étant le plus apte à être le prochain à poursuivre la mission et c'est tout".
Ainsi, traceroute permet, plus concrétement, de connaitre chaque point du chemin ET la décision de routage qui est fait à chacun de ces points .. en rapport à la seule destination qui a été demandée (et à d'autres facteurs secondaire, comme la disponnibilité, la saturation de l'une de ses connections).
9 202.97.49.5 (202.97.49.5) 387.694 ms 375.694 ms 395.659 ms
10 202.97.48.82 (202.97.48.82) 223.706 ms * 225.176 ms
Je sais que si je demande à 9 d'aller à 20, il va me router vers 10 .. Mais ça, seulement parce que je lui ai demandé d'aller à 20 => Fesons un premier traceroute (vers 20), et avec le résultat fesons un second traceroute vers le 15 trouvé par exemple : il y a une grande probabilité que le chemin soit complétement différent (beaucoup d'intérmédiaire entre les deux = grande chance que juste l'un d'entre eux prenne une décision différente parce que la destination a changée)
Et pour les temps, c'est exactement pareil : Lorsque je ping chaque routeur,
1. non seulement ma destination n'est pas la même, ce qui suggére que mon ping peut prendre à chaque fois un chemin différent en fonction de chaque destination
2. mais en plus, ma propre position, qui sera la destination de réponse du ping, va influencée à son tour le résultat, le chemin de "retour" n'étant pas forcément l'inverse du chemin "d'aller". (il me semble assez difficile en revanche de déterminer le chemin de retour)
Et là, je peux enfin analyser le résultat du traceroute : tiens, pour aller à 20, je passe par 18 puis 19, mais entre 0 (moi) et 19 c'est plus rapide que entre 0 et 18 ! Je pourrais faire un traceroute vers 18, un autre vers 19, et constater la différence entre les deux (ce serait surprenant, mais si y'en a pas, c'est que la différence se fait au retour), et j'en tire des conclusions. Mais là, à vue de nez, les décisions de routage entre 0 et 18 sont peut-être plus judicieuse que celles entre 0 et 19, puisqu'on voit en 19 qu'un paquet s'est peut être perdu, faudrait que je lance un ping sur 19 puis sur 18, histoire d'avoir plus de données et de savoir quel route est vraiment la meilleur (= rapide + stable) ... etc
Dans tous les cas, un seul traceroute ne suffit pas toujours, il faut l'agréementer de traceroutes intermédiaires, ainsi que de pings supplémentaires.
[^] # Re: Besoins de plus de données, de plus de pings et d'autres traceroutes
Posté par Viallet Vincent . Évalué à 2.
Il me semblait pourtant que lorsqu'on effectue un traceroute l'adresse de destination ne change pas, c'est seulement le TTL qui est incremente, ce qui signifierait donc que pour le chemin aller les regles de routage ne devraient pas etre modifiees (sauf si la valeur du champ TTL est prise en compte...). Donc le chemin ne devrait pas etre significativement change si les conditions du reseau restent similaires pendant les quelques minutes que dure le traceroute...
Apres pour le chemin de retour je suis d'accord avec le fait qu'il puisse etre different car le noeud precedent a l aller ne sera pas forcement optimal au retour. C'est ce qui a mon sens pourrait expliquer la difference de temps.
Apres je me plante peut etre :)
Autre question dans le genre, est il possible de decider par soit meme du chemin que doivent prendre les paquets sur le grand Ternet ? J'en doute mais bon :) Si par magie ca existe je suis preneur ! (20% de paquets perdus en moyenne ce n'est pas acceptable ...)
[^] # Re: Besoins de plus de données, de plus de pings et d'autres traceroutes
Posté par doublehp (site web personnel) . Évalué à 3.
ton erreur est la: un routeur se tape du TTL ( enfin presque ).
Si le TTL est nul, on renvoi a la source, sinon on continue. Un facteur tres important n aspas ete pris en compte dans le premier post: l encombrement des liens.
Un routeur de maniere generale cherche le meilleur moyen d acceder a la destination, MAIS, si une route est encombree ( lien sature, lien HS ... ), alors le routeur prends la decision d estimer la deuxiemme meilleur route. Si le 2e chemin est aussi inaccessible, il en cherche un 3e ... jusqu a se debarasser du paquet => un paquet peut arriver a faire 3 fois le tour du monde si le dernier lien vers la dst est sature, dans l esperance que la dst soit acessible pr doux routes, et que le paket tombe sur l entree de cette deuxiemme route.
C est cette particularite qui fait qu en treorie internet peut resister aux attaques par DOS de routeurs, et que la saturation ( ou supression ) d un lien fait que tous les elements sont toujours routes ( sauf les pauvres qui n ont qu un seul lien , comme toi sur ton ADSL)
est il possible de decider par soit meme du chemin que doivent prendre les paquets
si tu as compris ma precedente explication, tu c]dois comprendre pourquoi non: tu n est pas cense avoir conaissance des liens satures, c est pourquoi cette decision reviens a chaque routeur. et qui plus est, tu ne peut pas avoir conaissance des liens existant entre chaque noeuds ...
De ce point de vue, tu fais totalement confiance aux routeurs; mais ce n est pas vraiment une faille, car tout le monde as interret a faire son travaille le mieux possible ... dans l interret generale.
Si un pays decide de se fermer, il suprime les routes potentielle liant des ennemis se trouvant de parts ent d autres, mais il se coupe aussi l acces aux informations emanant des pays ennemis. S ili ferme une route sortante, il ne peut plus parler. Si il ferme une route rentrante, il ne peux plus recevoir la reponse. Tout le monde a donc grand interret a augmenter la taille des liens, voir a creer sur son propre territoire des liens accelerant l a communication de bout en bout ...
Ca as ete concu pour resister a une guerre globale, Ne l oublie pas. La chutte d un noeud ne doit penaliser que le neud concerne, et ceux qui lui sont relies par un lien unique.
[^] # Re: Besoins de plus de données, de plus de pings et d'autres traceroutes
Posté par Viallet Vincent . Évalué à 2.
Les criteres de routage que fournissent les paquets (adresse de destination identique...) restent inchanges, je ne parle pas de ce que les protocoles de routage des equipements reseaux prennent en compte (charge reseau etc... ).
Ce que je voulais dire par la c'est que je doute qu'effectuer un traceroute sur les noeuds precedents soit d'un grand secours.
On ne cherche plus a joindre l'IP finale mais un intermediaire : le protocole de routage selectionnera certainement une route plus avantageuse car il ne se base plus sur le meme critere qu'est l'adresse de destination.
Je sais bien que tout ce "bordel" est dynamique mais dans ce cas comment expliquer qu'un traceroute avec plus d'essais a chaque valeur de TTL renvoie generalement des valeurs pour les memes noeuds, plutot que des valeurs pour des noeuds distincts ? ( ex : traceroute -q 50 host_ip )
C'est bien qu'a un instant donne l'etat du reseau ne varie pas enormement ? Il est clair que si je fais le test 2 heures apres rien ne me certifie que j'emprunterai le meme chemin (comme ce devrait etre le cas d'une seconde a l'autre mais l'experience montre bien que ce n'est pas le cas).
Si ce n'est pas le cas il s'agirait alors d'une erreur de la part de traceroute lorsqu'il retourne les resultats il n'affiche pas pour chaque temps de retour l'IP de l'equipement qui me retourne le signal ICMP "Time Exceed".
Pour ce qui est du choix du chemin je me doutais de la reponse mais je pensais qu'il devait etre possible de determiner un chemin prioritaire (je ne maitrise pas le reseau en cause donc je n'y peux rien...)
La raison de cette question est simple : j'ai constate que lorsque j'essaie d'acceder a des sites francais 2 chemins principaux se dessinent (il y en a d'autres bien sur), dont un qui passe par un equipement qui me perd 25% des paquets... Genre acces a linuxfr.org / fnac.com / equipe.fr extremement long, mais acces a liberation.fr / telecomlille.net tres rapide...
Si je pouvais reussir a eviter cet equipement ca serait a mon avis pas mal ...
balou
[^] # Re: Besoins de plus de données, de plus de pings et d'autres traceroutes
Posté par doublehp (site web personnel) . Évalué à 1.
Si le chemin le plus court de A a D passe par C, et que le chemin le plus court de A ab C passe par B, alors le chemin le plus courn de A a D passe par B. C est mathematique.
donc : On ne cherche plus a joindre l'IP finale mais un intermediaire : le protocole de routage selectionnera certainement une route plus avantageuse car il ne se base plus sur le meme critere qu'est l'adresse de destination. me laisse tres perplexe.
Par ailleurs:
Si ce n'est pas le cas il s'agirait alors d'une erreur de la part de traceroute lorsqu'il retourne les resultats il n'affiche pas pour chaque temps de retour l'IP de l'equipement qui me retourne le signal ICMP "Time Exceed".
est aussi inexacte:
le routage sur internet n est pas fait a 100% en IP, mais en majorite en ATM. L IP est encapsule dans l ATM. Et la plus part des liens P2P sont ATM. Et comme c est proto different, tous les relais ATM n ont pas d IP. Il y a donc une tres gnarde part du routage internet qui echappe totalement a nos considerations 'traceroute' dans la mesure ou la plus part des machines qui routent nos trames nont pas d IPs en v4 ... donc sont invisibles pour no traceurs.
Il faut aussi considerer les routeurs transparents ... qui operent en IP, ont des IPs en v4, mais sont invisibles pour le monde, c est a dire ne sont pas pingables, ne changent pas le TTL ... bref font partie d un autre monde.
Bref, une trame peut traverser le monde de part en part en ne perdant qu un seul point de TTL, juste parcequ elle a trouve un chemin en ATM pour aller de la France a l Australie ... a ce moment, vous verrez un saut de seulement 1 en TTL, mais peut etre une latence enorme en terme de ping.
enfin, que les routeurs soient en ATM ou en IP/transparent, il arrive que cetraines machines forwardent l ICMP sur de soeurs ... ainsi, une machine donnee peut avoir une IP_v4, mais que celui qui repond au ping soit 4 sauts plus loin, dans une autre salle. Je ne connais pas le nom de cette procedure, mais je sais qu elle est courante dans le monde des grands; de la meme maniere, un routeur ATM peut ne pas avoir d IP_v4 reelle, mais un autre routeur peut se faire passer pour lui ... c est assez confus, fait ca existe.
Pour finir, je vous rappelle que quand les operateurs parlent de liens, ils ne parlent pas en Mb/s, mais en T/s ... genre par exemple, la fibre transmanche de la SNCF fait pres de 1m de diametre a la sortie du tunnel ... ca pars sur un routeur ... et a la sortie du routeur, il y a /des/ cables ethernet ... sur 4m de large sur 3m de haut ... a plus de 1Gb chacun ... vous voyez le debit ... ( sachant que chaque cable fait a peu pres 5mm de diametre ... )
bref, c est pas le genre d equipement equipe d un pentium, avec de la SDRAM, avec un bus a 100MHz et Windows dessus ... je suppose que ce genre d equipement n as pas non plus d IP au sens ou nous l entendons ...
Si vous voulez comprendre le routage, achetez un Oreilly sur le sujet, et preparez vous a bouffer de la theorie de graphes ... une des matieres les plus indigestes que je conaisse. ( et pourtant j aime les maths).
[^] # Re: Besoins de plus de données, de plus de pings et d'autres traceroutes
Posté par RuleZ . Évalué à 2.
Si A B C D sont des "groupes" de routeur (d'un même réseau), ça peut se vérifier (mais rien encore ne le garantit), mais si ce sont des routeurs précis, des hosts, il y a de forte chance que le chemin de A à C passe par B2 alors que celui de A à D passait par B.
Vulgairement : En fait, un routeur va router *par défaut* vers quelque chose de + global lorsqu'il ne sait pas vers où router. Et il va router vers quelque chose de + local lorsqu'il sait que c'est le moyen de s'approcher vraiment de la destination. Si je traceroute vers un intermédiaire, il y a des chance qu'un des mêmes routeurs du chemin précédent sache + tot vers quoi router en + local (il ne routera plus par défaut), et le trajet changera.
Sinon, balou, pour ce que tu veux faire, y'aurai un moyen de forcer la route, ce serai de passer par un proxy en france qui soit dans le groupe des sites auquels tu te connectes correctement. C'est du bricolage, ya des chance que ça agrave même ta connection en général, mais ça peut marcher.
[^] # Re: Besoins de plus de données, de plus de pings et d'autres traceroutes
Posté par Viallet Vincent . Évalué à 1.
c'est peut etre du bricolage mais je doute que ca agrave la situation vu ou on est ! (15s pour libe et 2min l'equipe)
merci
[^] # Re: Besoins de plus de données, de plus de pings et d'autres traceroutes
Posté par Viallet Vincent . Évalué à 1.
Merci bien pour toutes ces infos !
J'avoue m'y perdre... Plus je creuse plus je m'enfonce :) a la surface au moins ca a l'air sympa un traceroute !
Pout ta premiere remarque je suis d'accord c'est mathematique, j'ai beau chercher a te contredire je n'arrive pas a trouver la 'tite bete. Ca trotte ca trotte dans la tete mais faut que je me fasse une raison...
Je n'avais pas pense aux liens ATM c'est vrai...
J'espere tout de meme pouvoir resoudre mon probleme, si je peux !
En tout cas Markov c'est pas mon pote, comme tu dis c'est sacrement indigeste ! :)
Merci encore ca m'a tout de meme eclairci quelques points.
... sur ce c'est la fin de la journee j'va manger mon riz moi
[^] # Re: Besoins de plus de données, de plus de pings et d'autres traceroutes
Posté par doublehp (site web personnel) . Évalué à 1.
Probleme qui ne se pose pas dans le traffic aerien. j en conclus de le routage internet est encore pire que la gestion de traffic reel( terrestre, fluvial ou aerien ... ) ...
sans parler du probleme qu il a bien plus de routes sur internet que d autoroutes dans un pays, et que chaque routeur a plus de liaisons que les villes n ont de routes sortantes.
[^] # Re: Besoins de plus de données, de plus de pings et d'autres traceroutes
Posté par BiBite . Évalué à 1.
Toutes vos considérations sont drôlement intéressantes, mais j'ai une autre hypothèse (toute simple):
Je pense tout simplement que ta latence a une gigue assez élevée, ton "ping" n'est pas constant du tout. Et comme un traceroute fait autant de "ping" qu'il y a de routeurs entre toi et la destination que tu traces, tu as des chiffres qui ne sont pas croissants en fonction de l'éloignement des routeurs.
J'ai déjà eu le même genre de résultat que toi sur des destinations un peu lointaines et à chaque fois le ping vers ces detinations était relativement instable.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.