Paquets perdus
cLx
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)
3) ping 192.168.0.254
20 packets transmitted, 20 received, 0% packet loss, time 19000ms
rtt min/avg/max/mdev = 0.996/1.024/1.049/0.044 ms
=> OK, mon r�seau fonctionne
4) ping 88.181.202.254
20 packets transmitted, 20 received, 0% packet loss, time 19003ms
rtt min/avg/max/mdev = 20.392/27.447/47.559/7.102 ms
=> OK, ma liaison adsl semble fonctionner
5) ping lille-6k-1-a5.routers.proxad.net
20 packets transmitted, 20 received, 0% packet loss, time 19000ms
rtt min/avg/max/mdev = 20.969/25.647/41.053/5.251 ms
=> toujours ok
Bon, un petit coup de mtr:
Packets Pings
Host
Loss% Snt Last Avg Best Wrst StDev
1. 192.168.0.254
0.0% 10 1.1 1.2 1.1 1.5 0.1
2. 88.181.202.254
0.0% 10 23.2 25.9 20.2 44.6 6.9
3. lille-6k-1-a5.routers.proxad.net
0.0% 10 26.0 26.6 20.2 41.1 7.4
4. cbv-6k-2-v800.intf.routers.proxad.net
77.8% 10 37.5 33.0 28.6 37.5 6.3
5. bzn-crs16-1-be1002.intf.routers.proxad.net
0.0% 10 26.9 29.7 25.0 44.5 6.4
6. londres-6k-1-po101.intf.routers.proxad.net
33.3% 10 33.3 34.6 32.0 38.7 2.5
7. amsterdam-6k-1-po100.intf.routers.proxad.net
11.1% 10 41.2 43.4 41.0 48.5 2.6
8. francfort-6k-1-po101.intf.routers.proxad.net
0.0% 10 50.5 53.3 47.4 65.5 6.2
9. cr1.fra003.internap.net
0.0% 10 48.9 52.6 48.3 66.3 5.9
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 ? ;)
Merci d'avance,
cLx
> Packets Pings
> Host
> Loss% Snt Last Avg Best Wrst StDev
> 1. 192.168.0.254
> 0.0% 10 1.1 1.2 1.1 1.5 0.1
> 2. 88.181.202.254
> 0.0% 10 23.2 25.9 20.2 44.6 6.9
> 3. lille-6k-1-a5.routers.proxad.net
> 0.0% 10 26.0 26.6 20.2 41.1 7.4
> 4. cbv-6k-2-v800.intf.routers.proxad.net
> 77.8% 10 37.5 33.0 28.6 37.5 6.3
> 5. bzn-crs16-1-be1002.intf.routers.proxad.net
> 0.0% 10 26.9 29.7 25.0 44.5 6.4
> 6. londres-6k-1-po101.intf.routers.proxad.net
> 33.3% 10 33.3 34.6 32.0 38.7 2.5
> 7. amsterdam-6k-1-po100.intf.routers.proxad.net
> 11.1% 10 41.2 43.4 41.0 48.5 2.6
> 8. francfort-6k-1-po101.intf.routers.proxad.net
> 0.0% 10 50.5 53.3 47.4 65.5 6.2
> 9. cr1.fra003.internap.net
> 0.0% 10 48.9 52.6 48.3 66.3 5.9
>
> 77.8% de perte sur lille-6k-1-a5.routers.proxad.net, c'est normal ?
Stéphane Le Men
> 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.
Vincent Riquer
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
> 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
"Vincent Riquer" <vin...@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
Stéphane Le Men
"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
Dominique ROUSSEAU
> "Vincent Riquer" <vin...@riquer.fr> a �crit dans le message de
>
>> 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
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.