La Fibre
Télécom => Réseau => VPN => Discussion démarrée par: kaktuss77 le 21 juillet 2014 à 11:40:38
-
Bonjour,
alors voilà je rencontre un soucis de débit descendant à travers mon agrégation de liens VPN mais dans un cas précis.
Aucuns soucis lorsque le contenu vient d'internet. Aucune soucis depuis ma machine virtuelle Linux (Ubuntu server 12.10)
Mais depuis ma machine Windows (Windows 7) impossible de dépasser 1méga en down (je parle bien en bits/s) alors qu'avec ma machine Linux je suis bien a 10méga.
Le problème semble être lié à windows en soit car j'ai testé avec une VM Windows 8 fraichement installée et c'est pareil. SI vous avez une idée.
Schéma de l'installe
Machine client ---> Routeur ERL ---> Zeroshell_A -------VPN BONDING-----> Zeroshell_B -----> Machine virtuelle Linux ou Windows.
MTU à 1500octet partout.
La machine cliente à l'ERL en passerelle.
L'ERL à en passerelle par défaut le Zeroshell_A
Les machines distantes ont pour joindre la machine cliente en passerelle le Zeroshell_B.
Ca fait un petit moment et la je vois plus ce que je peux tester :(
Je précise que les machines distantes et le Zeroshell_B sont dans un datacenter virtualisées dans un ESXI 5.5 le tout raccordée en Gigabit à internet.
Les cartes réseaux virtuelles sont en Gigabit également.
edit : Si je transfère plusieurs fichiers en simultanés j'arrive bien à monter jusqu'a 10M
Edit 2 : Capture d'écran du débit de la VM Windows vers et depuis internet.
-
ajout des teste iperf
Machine Cliente vers VM distante Linux :
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.0.252 port 5001 connected with 172.16.20.100 port 40775
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-20.8 sec 25.8 MBytes 10.4 Mbits/sec
------------------------------------------------------------
Client connecting to 172.16.20.100, TCP port 5001
TCP window size: 19.4 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.0.252 port 44302 connected with 172.16.20.100 port 5001
[ 4] 0.0-22.8 sec 5.75 MBytes 2.12 Mbits/sec
Machine cliente vers VM distante Windows :
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.0.252 port 5001 connected with 172.16.0.10 port 60957
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-53.9 sec 6.75 MBytes 1.05 Mbits/sec
------------------------------------------------------------
Client connecting to 172.16.0.10, TCP port 5001
TCP window size: 256 KByte (WARNING: requested 4.00 MByte)
------------------------------------------------------------
[ 4] local 192.168.0.252 port 56706 connected with 172.16.0.10 port 5001
[ 4] 0.0-20.9 sec 5.12 MBytes 2.06 Mbits/sec
-
Et avec une autre solution de virtualisation ?
-
Bah je peux pas vraiment tester autres choses j'ai 27 VM qui tourne dans ce serveur héberger chez Online et je me vois pas prendre un autre serveur juste pour tester ça.
J'ai un ESXI en local chez moi et j'ai pas de soucis particulier entre mes VM Windows et mon réseau local. je plafonne au max de ce que peux faire le lien.
C'est que sur les VM Windows distantes. En local ça marche très bien. :/
J'ai re-épluché toute la conf des Zeroshell voir si j'avais pas une foutue règle de QOS qui traine car on voit un burst à 18Méga.
Server listening on TCP port 5001
TCP window size: 4.00 MByte
--------------------------------------------------
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 4.38 MBytes 18.4 Mbits/sec
[ 3] 2.0- 4.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 4.0- 6.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 6.0- 8.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 8.0-10.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 10.0-12.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 12.0-14.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 14.0-16.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 16.0-18.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 18.0-20.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 0.0-21.6 sec 6.75 MBytes 2.62 Mbits/sec
[ 3] local 172.16.0.10 port 5001 connected with 1
[ 3] 0.0- 2.0 sec 493 KBytes 2.02 Mbits/sec
[ 3] 2.0- 4.0 sec 487 KBytes 2.00 Mbits/sec
[ 3] 4.0- 6.0 sec 487 KBytes 1.99 Mbits/sec
[ 3] 6.0- 8.0 sec 391 KBytes 1.60 Mbits/sec
[ 3] 8.0-10.0 sec 529 KBytes 2.17 Mbits/sec
[ 3] 10.0-12.0 sec 492 KBytes 2.01 Mbits/sec
[ 3] 12.0-14.0 sec 498 KBytes 2.04 Mbits/sec
[ 3] 14.0-16.0 sec 507 KBytes 2.07 Mbits/sec
[ 3] 16.0-18.0 sec 487 KBytes 2.00 Mbits/sec
[ 3] 18.0-20.0 sec 494 KBytes 2.02 Mbits/sec
[ 3] 0.0-21.6 sec 5.12 MBytes 1.99 Mbits/sec
je vous fait un Iperf entre la VM Windows Distante et la Linux distante.
edit : c'est fait
Server listening on TCP port 5001
TCP window size: 4.00 MByte
------------------------------------------------------------
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 297 MBytes 1.24 Gbits/sec
[ 3] 2.0- 4.0 sec 294 MBytes 1.23 Gbits/sec
[ 3] 4.0- 6.0 sec 234 MBytes 982 Mbits/sec
[ 3] 6.0- 8.0 sec 108 MBytes 452 Mbits/sec
[ 3] 8.0-10.0 sec 116 MBytes 487 Mbits/sec
[ 3] 10.0-12.0 sec 116 MBytes 487 Mbits/sec
[ 3] 12.0-14.0 sec 110 MBytes 460 Mbits/sec
[ 3] 14.0-16.0 sec 116 MBytes 489 Mbits/sec
[ 3] 16.0-18.0 sec 117 MBytes 489 Mbits/sec
[ 3] 18.0-20.0 sec 113 MBytes 473 Mbits/sec
[ 3] 0.0-20.0 sec 1.58 GBytes 679 Mbits/sec
[ 3] local 172.16.0.10 port 5001 connected with 172.16.20.100 port 59539
[ 3] 0.0- 2.0 sec 94.3 MBytes 396 Mbits/sec
[ 3] 2.0- 4.0 sec 89.9 MBytes 377 Mbits/sec
[ 3] 4.0- 6.0 sec 90.8 MBytes 381 Mbits/sec
[ 3] 6.0- 8.0 sec 96.4 MBytes 404 Mbits/sec
[ 3] 8.0-10.0 sec 93.9 MBytes 394 Mbits/sec
[ 3] 10.0-12.0 sec 91.7 MBytes 385 Mbits/sec
[ 3] 12.0-14.0 sec 95.9 MBytes 402 Mbits/sec
[ 3] 14.0-16.0 sec 93.4 MBytes 392 Mbits/sec
[ 3] 16.0-18.0 sec 94.1 MBytes 395 Mbits/sec
[ 3] 18.0-20.0 sec 95.6 MBytes 401 Mbits/sec
[ 3] 0.0-20.0 sec 936 MBytes 392 Mbits/sec
-
Petit up?
J'ai installer un Windows tout frais, j'ai le même soucis. J'ai tester avec déférentes VMs à la maison et distante la machine Windows Distante on un débit de l'ordre de 1M dans le sens Distant ----> Maison.
J'ai même changer de routeur (virtualisé) c'est pareil.
Personne à une idée?
-
Combien de liens dans le bonding et leur vitesse dans chaque sens ?
éventuellement un test sans bonding pour voir?
Combien de latence de bout en bout?
sinon ca ressemble fort a un probleme TCP / TCP ACK. Il faudrait faire une capture.
-
Combien de liens dans le bonding et leur vitesse dans chaque sens ?
4 liens ADSL en bonding, j'applique du traffic shapping sur chaque lien pour que le débit soit exactement le même. soit 3.1Mbit/s en Down et 580Kbit/s UP.
soit un total de 4x3.1M down et 4x580k up
éventuellement un test sans bonding pour voir?
déjà testé, même symptôme mais que sur des machines Windows et pas Linux.
Combien de latence de bout en bout?
40ms de moyenne.
sinon ca ressemble fort a un probleme TCP / TCP ACK. Il faudrait faire une capture.
Si c'était un problème de TCP / TCP ACK, n'aurais-je pas le même problème avec mes machines Linux distantes?
je joint une image de l'infra réseau à mon domicile, le Zeroshell est raccorder à un autre Zeroshell-B a travers le Bonding d'interface et mes VM sont connectées sur ce Zeroshell-B
je le répète, aucune soucis quand c'est une machine Linux Distantes raccordée également sur ce Zeroshell-B. Les interface Virtuelles sont toutes des Intel E1000, Pas de Vlan coté distant.
-
Si c'était un problème de TCP / TCP ACK, n'aurais-je pas le même problème avec mes machines Linux distantes?
pas spécialement leur comportement sont différents.
C'est bien du VPN sur UDP pas TCP ?
Le mieux c'est une capture sinon tenter de jouer avec les paramètres coté Windows ou le type de carte réseau:
- "netsh interface tcp show global" permet de voir la config et sur quel parameters on peut jouer avec "netsh interface tcp set global". (bien noté les valeurs de départ pour remettre en l’état après les tests).
- faire un
netsh interface tcp set global rss=disabled chimney=disabled autotuninglevel=disabled
pour désactiver l'autotuning TCP de Windows (jouer sur les 3 paramètres éventuellement).
Prendre les drivers VMWare dans Windows (via VMWare Tools) et changer le type de carte réseau pour voir (VMXNET 3 plutot que E1000).
Il serait bien aussi de mesurer le mtu de bout en bout (avec "ping ipdistante -f -l taille". changer taille entre 1300 et 1500 par dichotomie pour trouver la valeur max ou en utilisant mtu-path (http://www.iea-software.com/products/mtupath.cfm)).
-
Je confirme que la pile TCP/IP de Windows est complètement différente de celle de Linux.
La pile TCP/IP de Windows est basé sur du code Free-BSD modifié par Microsoft.
A une époque (je ne sais pas si c'est encore le cas avec les Windows moderne), les timestamps ne s'activaient pas a cause d'un bug.
Il y a donc des comportements en cas de perte de paquet ou de-séquencement lié a ton agrégation de liens qui sont différents entre Windows et Linux.
Un dé-séquencement me semble le plus plausible comme problème. Il faudrait que tu réalises une capture Wireshark.
-
merci pour vos réponse à tous les deux.
Tous les VPN sont en UDP, sans compression, sans chiffrement.
J'ai oublié de préciser que j'avais déjà tester avec un autre type de carte virtuelle. (à force de tester plein de truc, on en oubli) actuelle je suis en VMX3. Les VMware tools sont installés.
avec la commande ping 172.16.0.10 -f -l xxxx, 1472 semble être mon maximum avant fragmentation.
J'ai pas mal de DUP ACK, mais pas de perte de paquet.
Je vais réaliser les captures Wireshark.
-
netsh interface tcp set global rss=disabled chimney=disabled autotuninglevel=disabled
pour désactiver l'autotuning TCP de Windows (jouer sur les 3 paramètres éventuellement).
Il y a un peu plus de paramètres que ça et il faut qu'ils soient cohérents avec ceux du driver.
cf http://lifeofageekadmin.com/network-performance-with-vmxnet3-on-windows-server-2008-r2/ (http://lifeofageekadmin.com/network-performance-with-vmxnet3-on-windows-server-2008-r2/)
De manière générale, pour savoir avec quoi "jouer"
http://msdn.microsoft.com/en-us/library/windows/hardware/dn529134 (http://msdn.microsoft.com/en-us/library/windows/hardware/dn529134)
-
Il ont unifé 2008 Server R2 et Windows 7 & 8 a ce niveau? A une époque, il y avait moins d'options sur la version desktop que la version server et certaines options ont pas la même valeur par défaut.
Ca peut valoir le coup de tenter avec une VM 2008R2 pour voir si y'a le même souci qu'avec Windows 7.
-
Il ont unifé 2008 Server R2 et Windows 7 & 8 a ce niveau?
Hormis des restrictions commerciales de type un share CIFS c'est max. XXX connections sur les versions client et illimité en version serveur...
En revanche, les réglages par défaut sont différents quand les clés de registre ne sont pas là
Sinon, le kernel et la pile TCP/IP sont les mêmes selon la logique : 2008R2 = 7, 2012=8, 2012R2 = 8.1 (en version 64-bit évidemment puisque depuis 2008R2 il n'y a plus de version serveur 32-bit).
Sinon je suppose qe la machine a été redemarrée depuis moins de 248 jours ;-) (cf. http://support.microsoft.com/kb/2553549/en-US (http://support.microsoft.com/kb/2553549/en-US) )
-
Alors j'ai tester avec du 7 64bit version pro, du 8.1 Version Pro en 64bits également, j'ai pas tester avec 2012 Server, je monte la VM et vous tiens au jus.
-
j'ai réalisé les capture wireshark, Linux distant vers Windows local (plein débit) et Windows distant vers Windows local (limité à 1Mbps)
IP du Linux distant : 172.16.20.100
IP du Windows distant : 172.16.0.10
IP du Windows local : 192.168.0.115
les captures hébergées sur mon cloud (https://cloud.geeker-tue.org/public.php?service=files&t=1754d934c2269549d9a2ec6e7db36b09)
edit : J'oubliais, tests réalisés avec Iperf avec la commande suivante : iperf -c 192.168.0.115 -i 2 -t 20
-
oula y'a énormèment de perte on dirait. La capture Windows montre déjà que l'ouverture de session n'a pas été acquittée (syn->syn-ack->perdu) et donc a du attendre 3 secondes (le timeout de TCP) avant de reprendre: ca fait deja 3 secondes sur 20s de test de perdu et ca n'est que le début.
Il faudrait faire des tests en UDP (avec iperf sur au moins une minute) pour mesurer le taux d'erreurs. et voir si c'est a peu près le meme suivant la machine en face (linux ou windows).
pour bien comparer,il faudrait aussi 2 captures non pas sur une durée commune mais sur un volume commun: genre un ftp ou un http du même fichier.
-
genre le transfère d'un fichier de 15Mo ça devrait le faire. bah je vais refaire le test en UDP alors
je vous poste ça des que c'est fait. en plus je suis pas chez moi alors tout ce fait en bureau a distance lol
-
A une époque (je ne sais pas si c'est encore le cas avec les Windows moderne), les timestamps ne s'activaient pas a cause d'un bug.
Heu sous Vista les timestamps TCP marchent mais je crois qu'ils sont désactivés par défaut.
-
Je viens de réaliser quelques tests en UDP avec Iperf (toujours avec les options i 2 et t 20) bah 1.05Mbit/s que ce soit avec le Linux distant ou le Windows Distant.
Log Iperf du windows distant :
[ 3] local 172.16.0.10 port 55465 connected with 192.168.0.115 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 257 KBytes 1.05 Mbits/sec
[ 3] 2.0- 4.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 4.0- 6.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 6.0- 8.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 8.0-10.0 sec 257 KBytes 1.05 Mbits/sec
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec
[ 3] Sent 893 datagrams
[ 3] WARNING: did not receive ack of last datagram after 10 tries.
Log du Linux distant :
------------------------------------------------------------
Client connecting to 192.168.0.115, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 3] local 172.16.20.100 port 58587 connected with 192.168.0.115 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 257 KBytes 1.05 Mbits/sec
[ 3] 2.0- 4.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 4.0- 6.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 6.0- 8.0 sec 257 KBytes 1.05 Mbits/sec
[ 3] 8.0-10.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 10.0-12.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 12.0-14.0 sec 257 KBytes 1.05 Mbits/sec
[ 3] 14.0-16.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 16.0-18.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 18.0-20.0 sec 257 KBytes 1.05 Mbits/sec
[ 3] 0.0-20.0 sec 2.50 MBytes 1.05 Mbits/sec
[ 3] Sent 1785 datagrams
[ 3] WARNING: did not receive ack of last datagram after 10 tries.
C'est quand même bizarre cette histoire de perte de paquets car depuis chez moi (donc en passant par mon agrégation de VPN) lorsque je fais un pingtest sur pingtest.net, packet loss j'ai 0% par contre j'ai pas mal de gigue.
De plus, lors de téléchargements de fichiers en provenance d'internet (http, ftp ou autre) je n'ai aucun soucis pour saturer mon agrégation de liens. (soit environ 11Mbps) cf : Fichier joint
Bon je m'en vais de se pas faire les capture wireshark d'un fichier de quelque Mo pour faire le test.
-
manque la fin de tes iperfs pour voir le bilan loss/out of order (bien mettre -u des 2 cotés).
par exemple:
Client connecting to XX.XX.XX.XX, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.42 port 62828 connected with XX.XX.XX.XX port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec
[ 3] Sent 893 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 8.551 ms 39/ 893 (4.4%)
[ 3] 0.0-10.0 sec 39 datagrams received out-of-order
la on voit 4.4% de perte.
en mode UDP iperf envoi par défaut a 1Mbps. le but c'est pas de mesurer le débit mais les pertes.
Pour 'foncer' en UDP, utilises l'option -b. par exemple '-b 100M' pour envoyer a 100Mbps.
Attention aussi en UDP, le client peut marcher meme si le serveur est eteint ou pas pres. bien verifier la presence de 'server report' ou avoir les 2 écrans sous les yeux. Et faire les tests dans l'autre sens aussi (ou avec -r).
-
Super, merci pour ta réponse :),
je vais tester le débit en UDP pour voir.
Oui j'ai les deux consoles de l'Iperf serveur et client sous le nez. J'ai bien activé l'option -u des deux cotés. (pas facile de débug un soucis chez soit quand on est a plus de 800km de son domicile lol)
Voila les captures Les nouvelles captures + traceroute (https://cloud.geeker-tue.org/public.php?service=files&t=1754d934c2269549d9a2ec6e7db36b09)
J'ai aussi testé le débit lorsque je passe par l'IP publique de mon Linux distant (ce qui me fait passer par la passerelle du datacenter. La capture est jointe.
J'ai fait 3 traceroute :
Windows Local --> Windows distant
Windows Local --> Linux distant (patte LAN)
Windows Local --> Linux distant (patte WAN)
EDIT : J'ai ajouter une capture, DL du fichier 20Mo.dat depuis le Linux distant vers un PC depuis une vraie connexion ADSL 14Mbps, histoire de comparer.
aller pour la route un petit Iperf depuis le Linux distant (VM dans un ESX) vers le serveur Iperf de lafibre.info
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 3.testdebit.info, TCP port 5001
TCP window size: 22.9 KByte (default)
------------------------------------------------------------
[ 5] local 212.83.147.104 port 53580 connected with 89.84.127.55 port 5001
[ ID] Interval Transfer Bandwidth
[ 5] 0.0- 2.0 sec 213 MBytes 894 Mbits/sec
[ 5] 2.0- 4.0 sec 217 MBytes 910 Mbits/sec
[ 5] 4.0- 6.0 sec 217 MBytes 912 Mbits/sec
[ 5] 6.0- 8.0 sec 217 MBytes 910 Mbits/sec
[ 5] 8.0-10.0 sec 218 MBytes 915 Mbits/sec
[ 5] 10.0-12.0 sec 218 MBytes 915 Mbits/sec
[ 5] 12.0-14.0 sec 218 MBytes 916 Mbits/sec
[ 5] 14.0-16.0 sec 218 MBytes 915 Mbits/sec
[ 5] 16.0-18.0 sec 218 MBytes 913 Mbits/sec
[ 5] 18.0-20.0 sec 218 MBytes 915 Mbits/sec
[ 5] 0.0-20.0 sec 2.12 GBytes 911 Mbits/sec
[ 4] local 212.83.147.104 port 5001 connected with 89.84.127.55 port 57109
[ 4] 0.0- 2.0 sec 203 MBytes 853 Mbits/sec
[ 4] 2.0- 4.0 sec 215 MBytes 903 Mbits/sec
[ 4] 4.0- 6.0 sec 215 MBytes 901 Mbits/sec
[ 4] 6.0- 8.0 sec 218 MBytes 913 Mbits/sec
[ 4] 8.0-10.0 sec 215 MBytes 904 Mbits/sec
[ 4] 10.0-12.0 sec 216 MBytes 908 Mbits/sec
[ 4] 12.0-14.0 sec 214 MBytes 899 Mbits/sec
[ 4] 14.0-16.0 sec 216 MBytes 908 Mbits/sec
[ 4] 16.0-18.0 sec 216 MBytes 907 Mbits/sec
[ 4] 18.0-20.0 sec 215 MBytes 900 Mbits/sec
[ 4] 0.0-20.0 sec 2.09 GBytes 899 Mbits/sec
-
Hello tout le monde,
je pense que je vais me répondre tout seul concernant mon soucis de débit depuis ma machine Windows.
Je viens de voir lors de test de débit depuis lafibre.info que j'ai une fenêtre TCP de 8192, (au départ c'était pour trouver le meilleurs compromis MSS - MTU à travers les VPN OpenVPN (il semblerait que de forcé la MSS à 900 n'impact pas sur les performances, bien au contraire j'ai gagné sur mon cumule de débit (basé sur 10 tests) je suis en train de voir pour forcé un MTU a 1400 avec mon UTM, mais je pense que ca ne changera rien.
Bref quoi qu'il en soit, devant se TCPdump en ligne de commande (retour affichage sur l'écran) je décide de lancer un test depuis mon windows (pour voir si la MSS a jouer sur ce probleme) et la je vois un Windows size à 65834, je vais baisser la fenetre de mon client windows.
car j'ai cru comprendre qu'une grande taille de WinTCP + gros ping faisait pas bon ménage.
On vera bien :)