Voilà, j'ai un intranet avec une 20aine de sites et je constate
occasionellement des paquets perdus (3-10%) entre certains points.
J'essaye de localiser les points faibles à l'aide de séries de tracert
:
c:\>for /l %i in (1,1,200) do tracert -d -w 10000 10.0.0.3
>>c:\tracelog.txt
J'ai donc un joli fichier texte qui contient 200 traceroutes qui
ressemblent à ça :
Détermination de l'itinéraire vers 10.0.0.3 avec un maximum de 30
sauts.
1 <1 ms <1 ms <1 ms 10.40.30.140
2 25 ms 25 ms 26 ms 172.16.0.9
3 47 ms 38 ms 40 ms 172.16.0.254
4 37 ms * 39 ms 192.168.1.252
5 * 46 ms 49 ms 172.16.0.250
6 49 ms 56 ms 71 ms 10.0.0.3
Mais je ne sais pas trop comment tracert fait son job.
(enfin, je me dis que si il y a encore des temps de réponses derrière
les '*' c'est qu'un autre paquet a été envoyé)
Sur la série de tracert, les '*' apparaissent principalement sur l'une
de ces 2 lignes comme dans l'exemple ci dessus. Peut on en conclure que
les paquets sont perdus entre le 173.16.0.254 et le 176.16.0.250 ?
Ou bien, on peut juste conclure que les paquets icmp ne sont pas
parvenus à l'un de ces 2 routeurs et qu'ils ont été perdus quelque part
avant eux mais on ne sais pas où ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
T0t0
"Alni" wrote in message news:
Mais je ne sais pas trop comment tracert fait son job.
Une petite explication là: <http://www.lalitte.com/reseau.html#tracert>
(enfin, je me dis que si il y a encore des temps de réponses derrière les '*' c'est qu'un autre paquet a été envoyé)
Oui, c'est le principe de traceroute.
Sur la série de tracert, les '*' apparaissent principalement sur l'une de ces 2 lignes comme dans l'exemple ci dessus. Peut on en conclure que les paquets sont perdus entre le 173.16.0.254 et le 176.16.0.250 ?
Perdus je ne pense pas, filtrés à l'aller ou au retour, peut-être. Y aurait-il des routes qui bagottent ?
Ou bien, on peut juste conclure que les paquets icmp ne sont pas parvenus à l'un de ces 2 routeurs et qu'ils ont été perdus quelque part avant eux mais on ne sais pas où ?
Exact. Le problème de traceroute est qu'il ne tient pas compte de la dynamicité du routage. Il faudrait peut-être essayer de voir si les tables de routage changent beaucoup ou sont stables.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Alni" <none@nowhere.com> wrote in message
news:mn.4a3f7d4c6c243d74.22859@nowhere.com
Mais je ne sais pas trop comment tracert fait son job.
Une petite explication là:
<http://www.lalitte.com/reseau.html#tracert>
(enfin, je me dis que si il y a encore des temps de réponses derrière
les '*' c'est qu'un autre paquet a été envoyé)
Oui, c'est le principe de traceroute.
Sur la série de tracert, les '*' apparaissent principalement sur l'une
de ces 2 lignes comme dans l'exemple ci dessus. Peut on en conclure que
les paquets sont perdus entre le 173.16.0.254 et le 176.16.0.250 ?
Perdus je ne pense pas, filtrés à l'aller ou au retour, peut-être.
Y aurait-il des routes qui bagottent ?
Ou bien, on peut juste conclure que les paquets icmp ne sont pas
parvenus à l'un de ces 2 routeurs et qu'ils ont été perdus quelque part
avant eux mais on ne sais pas où ?
Exact.
Le problème de traceroute est qu'il ne tient pas compte de la
dynamicité du routage. Il faudrait peut-être essayer de voir si les
tables de routage changent beaucoup ou sont stables.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Mais je ne sais pas trop comment tracert fait son job.
Une petite explication là: <http://www.lalitte.com/reseau.html#tracert>
(enfin, je me dis que si il y a encore des temps de réponses derrière les '*' c'est qu'un autre paquet a été envoyé)
Oui, c'est le principe de traceroute.
Sur la série de tracert, les '*' apparaissent principalement sur l'une de ces 2 lignes comme dans l'exemple ci dessus. Peut on en conclure que les paquets sont perdus entre le 173.16.0.254 et le 176.16.0.250 ?
Perdus je ne pense pas, filtrés à l'aller ou au retour, peut-être. Y aurait-il des routes qui bagottent ?
Ou bien, on peut juste conclure que les paquets icmp ne sont pas parvenus à l'un de ces 2 routeurs et qu'ils ont été perdus quelque part avant eux mais on ne sais pas où ?
Exact. Le problème de traceroute est qu'il ne tient pas compte de la dynamicité du routage. Il faudrait peut-être essayer de voir si les tables de routage changent beaucoup ou sont stables.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Jacques Caron
Salut,
On Thu, 09 Dec 2004 09:35:15 +0100, Alni wrote:
J'essaye de localiser les points faibles à l'aide de séries de tracert :
Pas la peine de faire des séries. Tracert sert plus à faire une première analyze pour voir le chemin (et éventuellement indentifier des points faibles), l'analyse précise se faisant généralement plutôt avec ping qui offre plus de souplesse (enfin, certaines versions en tous cas).
Mais je ne sais pas trop comment tracert fait son job.
Une petite recherche sur Google doit très probablement rapidement donner le résultat. Il envoie 3 paquets avec un TTL de 1, 3 paquets avec un TTL de 2, 3 paquets avec un TTL de 3 et ainsi de suite jusqu'à destination.
Sur la série de tracert, les '*' apparaissent principalement sur l'une de ces 2 lignes comme dans l'exemple ci dessus. Peut on en conclure que les paquets sont perdus entre le 173.16.0.254 et le 176.16.0.250 ?
Non.
Ou bien, on peut juste conclure que les paquets icmp ne sont pas parvenus à l'un de ces 2 routeurs et qu'ils ont été perdus quelque part avant eux mais on ne sais pas où ?
C'est plus vraisemblable. Le segment 172.16.0.254-192.168.1.252 est un bon candidat. Il suffit maintenant de faire une série de pings sur chaque adresse du chemin pour essayer d'identifier les problèmes.
Attention: certains équipements se prêtent mal aux diagnostics en n'émettant pas systématiquement de paquets ICMP en retour. C'est particulièrement vrai avec les routeurs cisco et traceroute.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Thu, 09 Dec 2004 09:35:15 +0100, Alni <none@nowhere.com> wrote:
J'essaye de localiser les points faibles à l'aide de séries de tracert :
Pas la peine de faire des séries. Tracert sert plus à faire une première
analyze pour voir le chemin (et éventuellement indentifier des points
faibles), l'analyse précise se faisant généralement plutôt avec ping qui
offre plus de souplesse (enfin, certaines versions en tous cas).
Mais je ne sais pas trop comment tracert fait son job.
Une petite recherche sur Google doit très probablement rapidement donner
le résultat. Il envoie 3 paquets avec un TTL de 1, 3 paquets avec un TTL
de 2, 3 paquets avec un TTL de 3 et ainsi de suite jusqu'à destination.
Sur la série de tracert, les '*' apparaissent principalement sur l'une
de ces 2 lignes comme dans l'exemple ci dessus. Peut on en conclure que
les paquets sont perdus entre le 173.16.0.254 et le 176.16.0.250 ?
Non.
Ou bien, on peut juste conclure que les paquets icmp ne sont pas
parvenus à l'un de ces 2 routeurs et qu'ils ont été perdus quelque part
avant eux mais on ne sais pas où ?
C'est plus vraisemblable. Le segment 172.16.0.254-192.168.1.252 est un bon
candidat. Il suffit maintenant de faire une série de pings sur chaque
adresse du chemin pour essayer d'identifier les problèmes.
Attention: certains équipements se prêtent mal aux diagnostics en
n'émettant pas systématiquement de paquets ICMP en retour. C'est
particulièrement vrai avec les routeurs cisco et traceroute.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
J'essaye de localiser les points faibles à l'aide de séries de tracert :
Pas la peine de faire des séries. Tracert sert plus à faire une première analyze pour voir le chemin (et éventuellement indentifier des points faibles), l'analyse précise se faisant généralement plutôt avec ping qui offre plus de souplesse (enfin, certaines versions en tous cas).
Mais je ne sais pas trop comment tracert fait son job.
Une petite recherche sur Google doit très probablement rapidement donner le résultat. Il envoie 3 paquets avec un TTL de 1, 3 paquets avec un TTL de 2, 3 paquets avec un TTL de 3 et ainsi de suite jusqu'à destination.
Sur la série de tracert, les '*' apparaissent principalement sur l'une de ces 2 lignes comme dans l'exemple ci dessus. Peut on en conclure que les paquets sont perdus entre le 173.16.0.254 et le 176.16.0.250 ?
Non.
Ou bien, on peut juste conclure que les paquets icmp ne sont pas parvenus à l'un de ces 2 routeurs et qu'ils ont été perdus quelque part avant eux mais on ne sais pas où ?
C'est plus vraisemblable. Le segment 172.16.0.254-192.168.1.252 est un bon candidat. Il suffit maintenant de faire une série de pings sur chaque adresse du chemin pour essayer d'identifier les problèmes.
Attention: certains équipements se prêtent mal aux diagnostics en n'émettant pas systématiquement de paquets ICMP en retour. C'est particulièrement vrai avec les routeurs cisco et traceroute.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Alni
Bonjour,
T0t0 avait soumis l'idée :
Une petite explication là: <http://www.lalitte.com/reseau.html#tracert> Oui, c'est le principe de traceroute.
Et oui, bien sûr : le TTL, Pffff j'ai même pas tilté ! En plus, j'ai des captures de trames faites avec Network Observer pendant l'opération, et j'ai du "ttl exceed" en pagaille...Evidement ! Même pas fait le rapprochement.
Perdus je ne pense pas, filtrés à l'aller ou au retour, peut-être. Y aurait-il des routes qui bagottent ?
Filtés ? Je ne vois pas trop pourquoi ils seraient filtrés. A moins que ce soit en raison du niveau de priorité des ICMP qui est normalement assez faible. Je pourrais essayer de recommencer en envoyant des paquets TCP vers le telnet de la machine cible, puisque c'est sur des transactions telnet que les ralentissements sont constatés. Et vu la dimension du réseau (majoritairement du 1024/256 - 160kbps garanti) les transactions telnet ne devraient pas occuper la bande passante. Network Observer en "what-If analysis" montre que l'occupation globale (UP/DN) est de <5% de la BP upload 256kpbs (9 pkt/s - 800ko de trafic au total dans les 2 sens sur 15mn de capture).
Le problème de traceroute est qu'il ne tient pas compte de la dynamicité du routage. Il faudrait peut-être essayer de voir si les tables de routage changent beaucoup ou sont stables.
Je n'ai pas acccès aux tables de routage, c'est l'opérateur telecom, qui gère les routeurs de mon Intranet. De même, pour répondre à Jacques :
C'est plus vraisemblable. Le segment 172.16.0.254-192.168.1.252 est un bon candidat. Il suffit maintenant de faire une série de pings sur chaque adresse du chemin pour essayer d'identifier les problèmes.
J'ai l'impression que je ne peux pas atteindre directement ces machines (en tous cas du site central où je suis actuellement) Il faudra que je retourne sur un des sites à problèmes. Même en corrigeant mes erreurs de typo "172" au lieu de "173" et "176" :)
Je peux toujours voir ce que je peux faire avec frameip avec le serveur en adresse cible et un ttl qui sera fixé à 2 puis 3 puis 4 etc...
Bref, il faut que je retourne sur un site....
-- Alni
Bonjour,
T0t0 avait soumis l'idée :
Une petite explication là:
<http://www.lalitte.com/reseau.html#tracert>
Oui, c'est le principe de traceroute.
Et oui, bien sûr : le TTL, Pffff j'ai même pas tilté !
En plus, j'ai des captures de trames faites avec Network Observer
pendant l'opération, et j'ai du "ttl exceed" en pagaille...Evidement !
Même pas fait le rapprochement.
Perdus je ne pense pas, filtrés à l'aller ou au retour, peut-être.
Y aurait-il des routes qui bagottent ?
Filtés ?
Je ne vois pas trop pourquoi ils seraient filtrés. A moins que ce soit
en raison du niveau de priorité des ICMP qui est normalement assez
faible.
Je pourrais essayer de recommencer en envoyant des paquets TCP vers le
telnet de la machine cible, puisque c'est sur des transactions telnet
que les ralentissements sont constatés. Et vu la dimension du réseau
(majoritairement du 1024/256 - 160kbps garanti) les transactions telnet
ne devraient pas occuper la bande passante. Network Observer en
"what-If analysis" montre que l'occupation globale (UP/DN) est de <5%
de la BP upload 256kpbs (9 pkt/s - 800ko de trafic au total dans les 2
sens sur 15mn de capture).
Le problème de traceroute est qu'il ne tient pas compte de la
dynamicité du routage. Il faudrait peut-être essayer de voir si les
tables de routage changent beaucoup ou sont stables.
Je n'ai pas acccès aux tables de routage, c'est l'opérateur telecom,
qui gère les routeurs de mon Intranet.
De même, pour répondre à Jacques :
C'est plus vraisemblable. Le segment 172.16.0.254-192.168.1.252 est un bon
candidat. Il suffit maintenant de faire une série de pings sur chaque
adresse du chemin pour essayer d'identifier les problèmes.
J'ai l'impression que je ne peux pas atteindre directement ces machines
(en tous cas du site central où je suis actuellement) Il faudra que je
retourne sur un des sites à problèmes.
Même en corrigeant mes erreurs de typo "172" au lieu de "173" et "176"
:)
Je peux toujours voir ce que je peux faire avec frameip avec le serveur
en adresse cible et un ttl qui sera fixé à 2 puis 3 puis 4 etc...
Une petite explication là: <http://www.lalitte.com/reseau.html#tracert> Oui, c'est le principe de traceroute.
Et oui, bien sûr : le TTL, Pffff j'ai même pas tilté ! En plus, j'ai des captures de trames faites avec Network Observer pendant l'opération, et j'ai du "ttl exceed" en pagaille...Evidement ! Même pas fait le rapprochement.
Perdus je ne pense pas, filtrés à l'aller ou au retour, peut-être. Y aurait-il des routes qui bagottent ?
Filtés ? Je ne vois pas trop pourquoi ils seraient filtrés. A moins que ce soit en raison du niveau de priorité des ICMP qui est normalement assez faible. Je pourrais essayer de recommencer en envoyant des paquets TCP vers le telnet de la machine cible, puisque c'est sur des transactions telnet que les ralentissements sont constatés. Et vu la dimension du réseau (majoritairement du 1024/256 - 160kbps garanti) les transactions telnet ne devraient pas occuper la bande passante. Network Observer en "what-If analysis" montre que l'occupation globale (UP/DN) est de <5% de la BP upload 256kpbs (9 pkt/s - 800ko de trafic au total dans les 2 sens sur 15mn de capture).
Le problème de traceroute est qu'il ne tient pas compte de la dynamicité du routage. Il faudrait peut-être essayer de voir si les tables de routage changent beaucoup ou sont stables.
Je n'ai pas acccès aux tables de routage, c'est l'opérateur telecom, qui gère les routeurs de mon Intranet. De même, pour répondre à Jacques :
C'est plus vraisemblable. Le segment 172.16.0.254-192.168.1.252 est un bon candidat. Il suffit maintenant de faire une série de pings sur chaque adresse du chemin pour essayer d'identifier les problèmes.
J'ai l'impression que je ne peux pas atteindre directement ces machines (en tous cas du site central où je suis actuellement) Il faudra que je retourne sur un des sites à problèmes. Même en corrigeant mes erreurs de typo "172" au lieu de "173" et "176" :)
Je peux toujours voir ce que je peux faire avec frameip avec le serveur en adresse cible et un ttl qui sera fixé à 2 puis 3 puis 4 etc...
Bref, il faut que je retourne sur un site....
-- Alni
T0t0
"Alni" wrote in message news:
Filtés ? Je ne vois pas trop pourquoi ils seraient filtrés. A moins que ce soit en raison du niveau de priorité des ICMP qui est normalement assez faible.
Parfois, certains routeurs filtrent l'icmp en tous genres qui leur est destiné. Comme ça, ils laissent passer l'ICMP, mais pas celui qui leur arrive. Ca peut être un pb pour traceroute (d'autant qu'il me semble que le traceroute windows se base sur de l'ICMP pour l'envoi) Faudrait voir avec un traceroute unix pour voir q'il y a des différences.
Je pourrais essayer de recommencer en envoyant des paquets TCP vers le telnet de la machine cible, puisque c'est sur des transactions telnet que les ralentissements sont constatés. Et vu la dimension du réseau (majoritairement du 1024/256 - 160kbps garanti) les transactions telnet ne devraient pas occuper la bande passante. Network Observer en "what-If analysis" montre que l'occupation globale (UP/DN) est de <5% de la BP upload 256kpbs (9 pkt/s - 800ko de trafic au total dans les 2 sens sur 15mn de capture).
C'est bizarre que ça le fasse que pour un protocole. Dans ce cas, le pb est peut-être applicatif. Sinon, voir tcptraceroute.
Je peux toujours voir ce que je peux faire avec frameip avec le serveur en adresse cible et un ttl qui sera fixé à 2 puis 3 puis 4 etc... Bref, il faut que je retourne sur un site....
Bon courage !
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Alni" <none@nowhere.com> wrote in message
news:mn.4a987d4c66cb84eb.22859@nowhere.com
Filtés ?
Je ne vois pas trop pourquoi ils seraient filtrés. A moins que ce soit
en raison du niveau de priorité des ICMP qui est normalement assez
faible.
Parfois, certains routeurs filtrent l'icmp en tous genres qui leur
est destiné. Comme ça, ils laissent passer l'ICMP, mais pas celui qui
leur arrive. Ca peut être un pb pour traceroute (d'autant qu'il me
semble que le traceroute windows se base sur de l'ICMP pour l'envoi)
Faudrait voir avec un traceroute unix pour voir q'il y a des
différences.
Je pourrais essayer de recommencer en envoyant des paquets TCP vers le
telnet de la machine cible, puisque c'est sur des transactions telnet
que les ralentissements sont constatés. Et vu la dimension du réseau
(majoritairement du 1024/256 - 160kbps garanti) les transactions telnet
ne devraient pas occuper la bande passante. Network Observer en
"what-If analysis" montre que l'occupation globale (UP/DN) est de <5%
de la BP upload 256kpbs (9 pkt/s - 800ko de trafic au total dans les 2
sens sur 15mn de capture).
C'est bizarre que ça le fasse que pour un protocole. Dans ce cas,
le pb est peut-être applicatif.
Sinon, voir tcptraceroute.
Je peux toujours voir ce que je peux faire avec frameip avec le serveur
en adresse cible et un ttl qui sera fixé à 2 puis 3 puis 4 etc...
Bref, il faut que je retourne sur un site....
Bon courage !
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Filtés ? Je ne vois pas trop pourquoi ils seraient filtrés. A moins que ce soit en raison du niveau de priorité des ICMP qui est normalement assez faible.
Parfois, certains routeurs filtrent l'icmp en tous genres qui leur est destiné. Comme ça, ils laissent passer l'ICMP, mais pas celui qui leur arrive. Ca peut être un pb pour traceroute (d'autant qu'il me semble que le traceroute windows se base sur de l'ICMP pour l'envoi) Faudrait voir avec un traceroute unix pour voir q'il y a des différences.
Je pourrais essayer de recommencer en envoyant des paquets TCP vers le telnet de la machine cible, puisque c'est sur des transactions telnet que les ralentissements sont constatés. Et vu la dimension du réseau (majoritairement du 1024/256 - 160kbps garanti) les transactions telnet ne devraient pas occuper la bande passante. Network Observer en "what-If analysis" montre que l'occupation globale (UP/DN) est de <5% de la BP upload 256kpbs (9 pkt/s - 800ko de trafic au total dans les 2 sens sur 15mn de capture).
C'est bizarre que ça le fasse que pour un protocole. Dans ce cas, le pb est peut-être applicatif. Sinon, voir tcptraceroute.
Je peux toujours voir ce que je peux faire avec frameip avec le serveur en adresse cible et un ttl qui sera fixé à 2 puis 3 puis 4 etc... Bref, il faut que je retourne sur un site....
Bon courage !
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Alni
Bonjour,
T0t0 vient de nous annoncer :
C'est bizarre que ça le fasse que pour un protocole. Dans ce cas, le pb est peut-être applicatif.
Parce qu'ils ne font QUE ça....du telnet ! Il y a bien un peu de mail et de bureautique réseau, mais les ralentissements surviennent même lorsqu'il n'y a pas de trafic bureautique. D'ailleurs j'ai aussi une capture sur 6-8 mn de TOUT le trafic du site, et c'est 12 pkt/s avec 1800Bytes/s de moyenne contre 450 Bytes/s sur le trafic telnet uniquement Sur de l'ADSL à 160kbps garanti avec une crête à 1024/256 ça devrait le faire !
-- Alni
Bonjour,
T0t0 vient de nous annoncer :
C'est bizarre que ça le fasse que pour un protocole. Dans ce cas,
le pb est peut-être applicatif.
Parce qu'ils ne font QUE ça....du telnet !
Il y a bien un peu de mail et de bureautique réseau, mais les
ralentissements surviennent même lorsqu'il n'y a pas de trafic
bureautique. D'ailleurs j'ai aussi une capture sur 6-8 mn de TOUT le
trafic du site, et c'est 12 pkt/s avec 1800Bytes/s de moyenne contre
450 Bytes/s sur le trafic telnet uniquement
Sur de l'ADSL à 160kbps garanti avec une crête à 1024/256 ça devrait le
faire !
C'est bizarre que ça le fasse que pour un protocole. Dans ce cas, le pb est peut-être applicatif.
Parce qu'ils ne font QUE ça....du telnet ! Il y a bien un peu de mail et de bureautique réseau, mais les ralentissements surviennent même lorsqu'il n'y a pas de trafic bureautique. D'ailleurs j'ai aussi une capture sur 6-8 mn de TOUT le trafic du site, et c'est 12 pkt/s avec 1800Bytes/s de moyenne contre 450 Bytes/s sur le trafic telnet uniquement Sur de l'ADSL à 160kbps garanti avec une crête à 1024/256 ça devrait le faire !
