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

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

Marsh Posté le 27-09-2001 à 23:00:28    

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)


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 27-09-2001 à 23:00:28   

Reply

Marsh Posté le 28-09-2001 à 00:03:10    

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


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 28-09-2001 à 03:53:58    

soyons solidaire  
 :bounce:  :bounce:  :bounce:


---------------
Terrible !!
Reply

Marsh Posté le 28-09-2001 à 09:27:57    

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 ?


---------------
J'y étais (à la plus longue CG, et viva CyberTool)©F_P
Reply

Marsh Posté le 28-09-2001 à 10:18:07    

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

Reply

Marsh Posté le 28-09-2001 à 14:30:42    

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

Reply

Marsh Posté le 28-09-2001 à 14:48:08    

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...

Reply

Marsh Posté le 28-09-2001 à 17:51:32    

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


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 28-09-2001 à 17:55:12    

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

 

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


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 01-10-2001 à 08:53:59    

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


---------------
J'y étais (à la plus longue CG, et viva CyberTool)©F_P
Reply

Marsh Posté le 01-10-2001 à 08:53:59   

Reply

Marsh Posté le 01-10-2001 à 20:35:35    

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


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 01-10-2001 à 20:37:42    

les colissions peuvent en etre les causes

Reply

Marsh Posté le 01-10-2001 à 20:40:48    

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...


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 15-10-2001 à 15:09:40    

:cry:


---------------
AC : SW-5993-1459-0978 / dani / THE REAL KRYSTOPHE (Miss) / Pinacolada   Hémisphère sud
Reply

Marsh Posté le 15-10-2001 à 15:47:40    

pkoi tu pleures ? raconte tout à tonton jubi ;)
 
-->les dns ne font ca que si tu te connectes pas avec une connect wanadoo...


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 15-10-2001 à 16:01:49    

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


---------------
AC : SW-5993-1459-0978 / dani / THE REAL KRYSTOPHE (Miss) / Pinacolada   Hémisphère sud
Reply

Marsh Posté le 15-10-2001 à 17:54:19    

:bounce:


---------------
AC : SW-5993-1459-0978 / dani / THE REAL KRYSTOPHE (Miss) / Pinacolada   Hémisphère sud
Reply

Marsh Posté le 16-10-2001 à 12:39:33    

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


---------------
Jubi Photos : Flickr - 500px
Reply

Marsh Posté le 16-10-2001 à 14:21:53    

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


---------------
pussal powa
Reply

Marsh Posté le 17-10-2001 à 18:35:35    

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...


---------------
Jubi Photos : Flickr - 500px
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed