J'ai un petit problème. Je suis chez free depuis un moment, et tout d'un
coup, paf, ça se met a merdouiller un peu, mais continuellement.
1) Configuration:
[PCs] => [Switch/Routeur chez moi] => [freebox en modem] => [Free ADSL]
2) traceroute perdu.com
traceroute to perdu.com (208.97.189.107), 30 hops max, 40 byte packets
1 Gateway (192.168.0.254) 1.079 ms 1.078 ms 1.069 ms
2 88.181.202.254 (88.181.202.254) 21.841 ms 58.694 ms 21.637 ms
3 lille-6k-1-a5.routers.proxad.net (213.228.12.190) 20.841 ms 21.516 ms
20.866 ms
4 * * *
5 bzn-crs16-1-be1002.intf.routers.proxad.net (212.27.50.189) 34.820 ms
34.651 ms 33.285 ms
6 londres-6k-1-po101.intf.routers.proxad.net (212.27.51.186) 56.377 ms *
42.600 ms
7 * amsterdam-6k-1-po100.intf.routers.proxad.net (212.27.56.42) 41.305 ms
40.625 ms
8 francfort-6k-1-po101.intf.routers.proxad.net (212.27.56.37) 48.737 ms
49.063 ms 49.640 ms
(etc etc etc)
77.8% de perte sur lille-6k-1-a5.routers.proxad.net, c'est normal ?
Est-ce a cause de ça que je peux même plus regarder les guignols sans devoir
relancer le stream 10 fois ? ;)
77.8% de perte sur lille-6k-1-a5.routers.proxad.net, c'est normal ?
Je voulais bien dire : cbv-6k-2-v800.intf.routers.proxad.net
Stéphane Le Men
77.8% de perte sur lille-6k-1-a5.routers.proxad.net, c'est normal ?
Je voulais bien dire : cbv-6k-2-v800.intf.routers.proxad.net
les routes de retour ne sont pas forcement les mêmes pour chaque hop, en plus free est expert en DPI donc de nos jours, la performance reseau se mesure uniquement par protocole. En gros, la perf icmp n'a souvent plus rien à voire avec la perf udp ou tcp.
77.8% de perte sur lille-6k-1-a5.routers.proxad.net, c'est normal ?
Je voulais bien dire : cbv-6k-2-v800.intf.routers.proxad.net
les routes de retour ne sont pas forcement les mêmes pour chaque
hop, en plus free est expert en DPI donc de nos jours, la performance
reseau se mesure uniquement par protocole. En gros, la perf icmp
n'a souvent plus rien à voire avec la perf udp ou tcp.
77.8% de perte sur lille-6k-1-a5.routers.proxad.net, c'est normal ?
Je voulais bien dire : cbv-6k-2-v800.intf.routers.proxad.net
les routes de retour ne sont pas forcement les mêmes pour chaque hop, en plus free est expert en DPI donc de nos jours, la performance reseau se mesure uniquement par protocole. En gros, la perf icmp n'a souvent plus rien à voire avec la perf udp ou tcp.
77.8% de perte sur lille-6k-1-a5.routers.proxad.net, c'est normal ?
Je voulais bien dire : cbv-6k-2-v800.intf.routers.proxad.net
Tu as 0.0% sur la destination, donc aucun soucis. Ton mtr montre juste que cbv-6k-2-v800.intf.routers.proxad.net n'a pas toujours envie d'envoyer ICMP TTL Exceeded. C'est courant, et ça n'a rien à voir avec ton problème.
77.8% de perte sur lille-6k-1-a5.routers.proxad.net, c'est normal ?
Je voulais bien dire : cbv-6k-2-v800.intf.routers.proxad.net
Tu as 0.0% sur la destination, donc aucun soucis. Ton mtr montre juste
que cbv-6k-2-v800.intf.routers.proxad.net n'a pas toujours envie
d'envoyer ICMP TTL Exceeded. C'est courant, et ça n'a rien à voir avec
ton problème.
77.8% de perte sur lille-6k-1-a5.routers.proxad.net, c'est normal ?
Je voulais bien dire : cbv-6k-2-v800.intf.routers.proxad.net
Tu as 0.0% sur la destination, donc aucun soucis. Ton mtr montre juste que cbv-6k-2-v800.intf.routers.proxad.net n'a pas toujours envie d'envoyer ICMP TTL Exceeded. C'est courant, et ça n'a rien à voir avec ton problème.
cLx
Merci aux deux personnes qui ont répondus.
les routes de retour ne sont pas forcement les mêmes pour chaque hop, en plus free est expert en DPI donc de nos jours, la performance reseau se mesure uniquement par protocole. En gros, la perf icmp n'a souvent plus rien à voire avec la perf udp ou tcp.
Ok, je vais jouer un peu avec tcptraceroute alors.
Tu as 0.0% sur la destination, donc aucun soucis. Ton mtr montre juste que cbv-6k-2-v800.intf.routers.proxad.net n'a pas toujours envie d'envoyer ICMP TTL Exceeded. C'est courant, et ça n'a rien à voir avec ton problème.
Ok, compris. Vraiment par curiosité, pour ce genre de problèmes (de performances, pas un truc vraiment down), existe t'il une méthode plus fiable que les méthodes classiques pour déterminer "où" se trouve le hic ?
-- cLx
Merci aux deux personnes qui ont répondus.
les routes de retour ne sont pas forcement les mêmes pour chaque
hop, en plus free est expert en DPI donc de nos jours, la performance
reseau se mesure uniquement par protocole. En gros, la perf icmp
n'a souvent plus rien à voire avec la perf udp ou tcp.
Ok, je vais jouer un peu avec tcptraceroute alors.
Tu as 0.0% sur la destination, donc aucun soucis. Ton mtr montre juste
que cbv-6k-2-v800.intf.routers.proxad.net n'a pas toujours envie
d'envoyer ICMP TTL Exceeded. C'est courant, et ça n'a rien à voir avec
ton problème.
Ok, compris. Vraiment par curiosité, pour ce genre de problèmes (de
performances, pas un truc vraiment down), existe t'il une méthode plus fiable
que les méthodes classiques pour déterminer "où" se trouve le hic ?
les routes de retour ne sont pas forcement les mêmes pour chaque hop, en plus free est expert en DPI donc de nos jours, la performance reseau se mesure uniquement par protocole. En gros, la perf icmp n'a souvent plus rien à voire avec la perf udp ou tcp.
Ok, je vais jouer un peu avec tcptraceroute alors.
Tu as 0.0% sur la destination, donc aucun soucis. Ton mtr montre juste que cbv-6k-2-v800.intf.routers.proxad.net n'a pas toujours envie d'envoyer ICMP TTL Exceeded. C'est courant, et ça n'a rien à voir avec ton problème.
Ok, compris. Vraiment par curiosité, pour ce genre de problèmes (de performances, pas un truc vraiment down), existe t'il une méthode plus fiable que les méthodes classiques pour déterminer "où" se trouve le hic ?
-- cLx
Stéphane Le Men
"cLx" 'aimail.com.almost.invalid> a écrit dans le message de news:hrk558$mft$
Ok, compris. Vraiment par curiosité, pour ce genre de problèmes (de performances, pas un truc vraiment down), existe t'il une méthode plus fiable que les méthodes classiques pour déterminer "où" se trouve le hic ?
En présence de DPI, je n'ai pas de methode toute faite. Mais appliquer la méthode standart avec des générateurs de traffic specifiques doit donner des resultats. C'est plus dure, car il faut non seulement mettre en évidence un probleme de congestion, mais aussi les priorités de la DPI. C'est bien cette raison qui me fait fuire free. Mais bon, d'ici quelques années, je risque de devoir fuire tous les fai.
En tous cas, les pires sont les operateurs mobiles qui te balancent les reply de tes ping jusqu'a 10 secondes plus tard, alors qu'en tcp ca roule. Par contre, c'est tres utile pour l'operateur car lui, il facture aussi au volume
"cLx" <clx.kat@j'aimail.com.almost.invalid> a écrit dans le message de
news:hrk558$mft$1@news.trigofacile.com...
Ok, compris. Vraiment par curiosité, pour ce genre de problèmes (de
performances, pas un truc vraiment down), existe t'il une méthode plus
fiable
que les méthodes classiques pour déterminer "où" se trouve le hic ?
En présence de DPI, je n'ai pas de methode toute faite. Mais appliquer
la méthode standart avec des générateurs de traffic specifiques doit
donner des resultats. C'est plus dure, car il faut non seulement mettre
en évidence un probleme de congestion, mais aussi les priorités de la
DPI. C'est bien cette raison qui me fait fuire free. Mais bon, d'ici
quelques
années, je risque de devoir fuire tous les fai.
En tous cas, les pires sont les operateurs mobiles qui te balancent les
reply de tes ping jusqu'a 10 secondes plus tard, alors qu'en tcp ca roule.
Par contre, c'est tres utile pour l'operateur car lui, il facture aussi au
volume
"cLx" 'aimail.com.almost.invalid> a écrit dans le message de news:hrk558$mft$
Ok, compris. Vraiment par curiosité, pour ce genre de problèmes (de performances, pas un truc vraiment down), existe t'il une méthode plus fiable que les méthodes classiques pour déterminer "où" se trouve le hic ?
En présence de DPI, je n'ai pas de methode toute faite. Mais appliquer la méthode standart avec des générateurs de traffic specifiques doit donner des resultats. C'est plus dure, car il faut non seulement mettre en évidence un probleme de congestion, mais aussi les priorités de la DPI. C'est bien cette raison qui me fait fuire free. Mais bon, d'ici quelques années, je risque de devoir fuire tous les fai.
En tous cas, les pires sont les operateurs mobiles qui te balancent les reply de tes ping jusqu'a 10 secondes plus tard, alors qu'en tcp ca roule. Par contre, c'est tres utile pour l'operateur car lui, il facture aussi au volume
Dominique ROUSSEAU
Le dim, 02 mai 2010 at 15:22 GMT, Stéphane Le Men a écrit :
"Vincent Riquer" a écrit dans le message de news:hrk39i$1vm$
Ton mtr montre juste que cbv-6k-2-v800.intf.routers.proxad.net n'a pas toujours envie d'envoyer ICMP TTL Exceeded.
Ce n'est pas une envie, ils sont perdus sur le segment de retour vu que la destination finale a 0% de lost et que les segments aller sont superposés à chaque hop
Pour qu'un paquet ne soit pas reçu, il se peut qu'il se soit perdu en route. Mais il se peut aussi tout simplement qu'il ne soit pas émis. La plupart des routeurs "hard" du coeur de réseau des opérateurs gérant l'ICMP (en réception et émission) en "soft", il y a souvent une limite au nombre de paquets de ce type qu'ils vont traiter, pour ménager le processeur de gestion.
Et comme le dit Vincent, tnat que tu arrives à joindre la destination sans problème, tu n'a pas à t'inquiéter de ce que répondent ou non les routeurs intermédiaires.
Le dim, 02 mai 2010 at 15:22 GMT, Stéphane Le Men <slm@nullpart.fr> a écrit :
"Vincent Riquer" <vincent@riquer.fr> a écrit dans le message de
news:hrk39i$1vm$1@solo.fdn.fr...
Ton mtr montre juste
que cbv-6k-2-v800.intf.routers.proxad.net n'a pas toujours envie
d'envoyer ICMP TTL Exceeded.
Ce n'est pas une envie, ils sont perdus sur le segment de retour vu que
la destination finale a 0% de lost et que les segments aller sont
superposés à chaque hop
Pour qu'un paquet ne soit pas reçu, il se peut qu'il se soit perdu en
route.
Mais il se peut aussi tout simplement qu'il ne soit pas émis.
La plupart des routeurs "hard" du coeur de réseau des opérateurs gérant
l'ICMP (en réception et émission) en "soft", il y a souvent une limite
au nombre de paquets de ce type qu'ils vont traiter, pour ménager le
processeur de gestion.
Et comme le dit Vincent, tnat que tu arrives à joindre la destination
sans problème, tu n'a pas à t'inquiéter de ce que répondent ou non les
routeurs intermédiaires.
Le dim, 02 mai 2010 at 15:22 GMT, Stéphane Le Men a écrit :
"Vincent Riquer" a écrit dans le message de news:hrk39i$1vm$
Ton mtr montre juste que cbv-6k-2-v800.intf.routers.proxad.net n'a pas toujours envie d'envoyer ICMP TTL Exceeded.
Ce n'est pas une envie, ils sont perdus sur le segment de retour vu que la destination finale a 0% de lost et que les segments aller sont superposés à chaque hop
Pour qu'un paquet ne soit pas reçu, il se peut qu'il se soit perdu en route. Mais il se peut aussi tout simplement qu'il ne soit pas émis. La plupart des routeurs "hard" du coeur de réseau des opérateurs gérant l'ICMP (en réception et émission) en "soft", il y a souvent une limite au nombre de paquets de ce type qu'ils vont traiter, pour ménager le processeur de gestion.
Et comme le dit Vincent, tnat que tu arrives à joindre la destination sans problème, tu n'a pas à t'inquiéter de ce que répondent ou non les routeurs intermédiaires.
