Au vrais pros du réseau : Masquerading, MTU, Rwin, et packet loss...

Recherche :

Dernière réponse
Sujet : Au vrais pros du réseau : Masquerading, MTU, Rwin, et packet loss...
Jubijub	euh,le pb a été résolu : ca venait des DNS wanadoo, qui refusent qu'on s'y connecte plus de 4x si la connection n'est pas une connection wanadoo.. -->les 4 premier paquets passaient, et pas le reste...d'où le paquet loss fixe, que je trouvais douteux...

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

Jubijub

euh,le pb a été résolu : ca venait des DNS wanadoo, qui refusent qu'on s'y connecte plus de 4x si la connection n'est pas une connection wanadoo..

-->les 4 premier paquets passaient, et pas le reste...d'où le paquet loss fixe, que je trouvais douteux...

theplayer-thelast

Jubijub a écrit a écrit :

Citation :

[root@localhost /root]# ifconfig -a
eth0 Lien encap:Ethernet HWaddr 00:01:02:32:BC:C3
inet adr:192.168.0.1 Bcast:192.168.0.255 Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1452 Metric:1
Paquets Reçus:2696 erreurs:0 jetés:0 débordements:0 trames:0
Paquets transmis:2650 erreurs:0 jetés:0 débordements:0 carrier:0
collisions:0 lg file transmission:100
Interruption:10 Adresse de base:0xd400

eth1 Lien encap:Ethernet HWaddr 00:50:BA:A2:F8:82
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Paquets Reçus:2885 erreurs:0 jetés:0 débordements:0 trames:0
Paquets transmis:2854 erreurs:0 jetés:0 débordements:0 carrier:0
collisions:0 lg file transmission:100
Interruption:5 Adresse de base:0xd800

lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
Paquets Reçus:0 erreurs:0 jetés:0 débordements:0 trames:0
Paquets transmis:0 erreurs:0 jetés:0 débordements:0 carrier:0
collisions:0 lg file transmission:0

ppp0 Lien encap:Protocole Point-à-Point
inet adr:80.65.230.220 P-t-P:194.206.78.3 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
Paquets Reçus:2883 erreurs:0 jetés:0 débordements:0 trames:0
Paquets transmis:2852 erreurs:0 jetés:0 débordements:0 carrier:0
collisions:0 lg file transmission:10

y'a pas de packet loss la, mais pourtant :

Citation :

[root@localhost /root]# ping -c 30 ftp.nerim.net
Warning: no SO_TIMESTAMP support, falling back to SIOCGSTAMP
PING metroid.nerim.net (62.4.16.80) from 80.65.230.220 : 56(84) bytes of data.
64 bytes from metroid.nerim.net (62.4.16.80): icmp_seq=0 ttl=61 time=65.601 msec
64 bytes from metroid.nerim.net (62.4.16.80): icmp_seq=1 ttl=61 time=65.125 msec
64 bytes from metroid.nerim.net (62.4.16.80): icmp_seq=2 ttl=61 time=65.817 msec

--- metroid.nerim.net ping statistics ---
30 packets transmitted, 4 packets received, 86% packet loss
round-trip min/avg/max/mdev = 65.125/65.418/65.817/0.300 ms
[root@localhost /root]#

alors que si je fais le même ping sous dos sous ma WS(nombre de paquet 30, ftp.nerim.fr), ben g 0% packet loss

c'est le coté obscure des réseaux :D
bon, tu peux me donner le resultat de

tcpdump -i ppp0 > jesuce
avec les 2 cas

ping linux et ping 20doses

Jubijub

j'ai répondu complètement sur ton autre topic, va checker ;)

THE REAL KRYSTOPHE

:bounce:

THE REAL KRYSTOPHE

http://forum.hardware.fr/forum2.ph [...] &owntopic=

Jubijub

pkoi tu pleures ? raconte tout à tonton jubi ;)

-->les dns ne font ca que si tu te connectes pas avec une connect wanadoo...

THE REAL KRYSTOPHE

:cry:

Jubijub

en fait les DNS wanadoo font passer les 4 premiers paquets, et bloquent tt le reste...du coup, je perdais automatiquement 26 paquets sur 30...

fabcool

les colissions peuvent en etre les causes

Jubijub

un truc me chiffonnait, ct que le taux de paquet loss sous la GW était tjs le même...

-->g trouvé : gt resté sur les DNS wanadoo, qui visiblement n'aiment pas les connections autres que wanadoo...bilan, g corrigé, et g plus de paquet loss

French_Phoenix

Le pb est de savoir ou tu perds les paquets? Entre ta machine et le routeur ou entre ton routeur et le fai.

Jubijub

Citation :

y'a pas de packet loss la, mais pourtant :

Citation :

alors que si je fais le même ping sous dos sous ma WS(nombre de paquet 30, ftp.nerim.fr), ben g 0% packet loss

[edtdd]--Message édité par Jubijub--[/edtdd]

Jubijub

chr_79 a écrit a écrit :

monte la mtu de linux à 1500 sur les eth
sinon, sous linux, tu as une interface ppp0 ? si oui, donne son mtu

les trames de pppoe sont limitée à 1492

xpoop

as tu fais un traceroute pour savoir de quel hope venait le probleme exactement?
Car je n'ai jamais encore entendu qq'un se plaindre de packet loss sur sa passerelle linux...

kawa31

regarde la, le dernier article.
je me suis basé la dessus pour optimiser la mienne (pour les variables et sniffer pour determiner l'optimum car j'ai pas le meme PPT que l'article.)
Par contre sous linux je connais pas d'outils analyse de trame, mais q sur le forum doit bien connaitre un truc.
commence avec un seul pc en connect directe adsl, car sinon tu vas t arracher les cheveux.

http://www.adsl-france.org/contrib/b/a15a7.htm

chr_79

monte la mtu de linux à 1500 sur les eth
sinon, sous linux, tu as une interface ppp0 ? si oui, donne son mtu

French_Phoenix

Tu les perds ou tes paquets? entre ton fai et ton gateway ou entre tes pc et ton gateway?
En regardant les param de ta CArte rezo il me semble que c'est entre ton fai et ton gateway, non ?

nono_le_terribl

soyons solidaire
:bounce: :bounce: :bounce:

Jubijub

UP...je sais pas pourquoi, je sens que ce n'est que le premier d'une longue série

Jubijub

Après test intensif depuis deux jours, je viens de me rendre compte que j'ai un packet loss assez elevé...trop d'ailleurs, ca nuit à mes perfs.

Ma situation est la suivante : g une connection ADSL net1 PPPoEmasqueradée par une gateway linux RH7.1, et 2 pc branchés dessus.

Le PPPoE admet une MTU maximum de 1492 (1464 + header de 28).

La carte rézo de ma GW est configurée comme ca :

Citation :

eth0 Lien encap:Ethernet HWaddr 00:01:02:32:BC:C3
inet adr:192.168.0.1 Bcast:192.168.0.255 Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1452 Metric:1
Paquets Reçus:39742 erreurs:0 jetés:0 débordements:0 trames:0
Paquets transmis:39389 erreurs:0 jetés:0 débordements:0 carrier:0
collisions:0 lg file transmission:100
Interruption:10 Adresse de base:0xd400

La MTU a été mise à 1456 par RP-PPPoE.

Sous windows, ma MTU est aussi à 1456 (détection automatique de la MTU d'après le premier Hop sur le rézo), et ma rwin a été rabaissée à 13.000 .

-->donc windows n'est pas le problème, tous les settings pouvant induire un packet loss sont en dessous de leur valeur nominale

Sous linux par contre, j'ai deux problèmes : je ne sais pas comment abaisser la rwin (receive window), et y'a le masq.

Je me suis dit : si ma WS windows envoit à la GW un paquet qui fait 1456, comment est la taille du paquet une fois masqueradé ? Je ne me souviens plus si le masq change le header du paquet, ou si il l'encapsule dans un nouveau paquet, donc avec un nouveau header...
-->si le header est juste changé, c pas le pb
-->si le header est rajouté, alors avec un nouveau header, je dépasse la MTU du PPPoE, et du coup, tt mes paquets sont fragmentés...

J'ai aucun controle sur la MTU windows, qui dépend de celle de linux.

Donc pour diminuer mon paquet loss, à priori, je dois soit baisser encore la MTU si c la taille qui est en cause
-->soit baisser cette putain de rwin sous linux...je sais que c un réglage kernel, donc dans /proc, mais je sais pas précismént lequel choisir, y'en a 5 qui parlent plus ou moins de mémoire tampon pour les paquets...

Si qqn a une idée, je suis preneur

(à noter que ca a lieu avec 2 ISP différents, donc ce n'est pas un ISP en particulier qui est responsable, à la rigueur FT si tant est que netissimo aie un impact sur le paquet loss)