La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => 
OVHcloud => Discussion démarrée par: yazur le 23 juin 2021 à 09:29:10
-
Bonjour,
J'aimerais savoir si nos débits en upload testé avec Iperf sont normaux en sachant que notre bande passante est de 3Gbit/s symétrique :
TCP : (source --> destination = débit)
OVH ROUBAIX --> paris.testdebit.info = 35 Mo/s
OVH ROUBAIX --> lille.testdebit.info = 24 Mo/s
OVH ROUBAIX --> lyon.testdebit.info = 32 Mo/s
OVH ROUBAIX --> aix-marseille.testdebit.info = 19 Mo/s
UDP : (source --> destination = débit envoi source - débit reçu destination)
OVH ROUBAIX --> paris.testdebit.info = 485 Mo/s - 285 Mo/s
OVH ROUBAIX --> lille.testdebit.info = 508 Mo/s - 260 Mo/s
OVH ROUBAIX --> lyon.testdebit.info = 478 Mo/s - 279 Mo/s
OVH ROUBAIX --> aix-marseille.testdebit.info = 488 Mo/s - 273 Mo/s
Latence :
OVH ROUBAIX --> paris.testdebit.info = 5ms
OVH ROUBAIX --> lille.testdebit.info = 9ms
OVH ROUBAIX --> lyon.testdebit.info = 10ms
OVH ROUBAIX --> aix-marseille.testdebit.info = 14ms
Traceroute :
OVH ROUBAIX --> paris.testdebit.info = https://nsa40.casimages.com/img/2021/06/23/210623101816437979.png
OVH ROUBAIX --> lille.testdebit.info = https://nsa40.casimages.com/img/2021/06/23/210623101815917097.png
OVH ROUBAIX --> lyon.testdebit.info = https://nsa40.casimages.com/img/2021/06/23/210623101815838866.png
OVH ROUBAIX --> aix-marseille.testdebit.info = https://nsa40.casimages.com/img/2021/06/23/210623101816176493.png
-
Je viens d'ajouter plus d'informations dans le post initial (Latence + Traceroute)
-
LOL vous avez un doute sur la qualité du réseau de votre super hébergeur ?
Je doute que celui-ci vous garantisse les 3 Gbit/s. Donc la question à se poser est : est-ce que j'ai un problème à l'usage ou pas ? Si pas de problème, tout va bien, on s'en fou de ne pas avoir 3 Gbit/s vers le monde entier.
S'il y a un problème par contre, il faudra être plus précis plutôt que de faire des tests vers n'importe où.
-
LOL vous avez un doute sur la qualité du réseau de votre super hébergeur ?
Je doute que celui-ci vous garantisse les 3 Gbit/s. Donc la question à se poser est : est-ce que j'ai un problème à l'usage ou pas ? Si pas de problème, tout va bien, on s'en fou de ne pas avoir 3 Gbit/s vers le monde entier.
S'il y a un problème par contre, il faudra être plus précis plutôt que de faire des tests vers n'importe où.
Bonjour,
Vous me semblez quelque peu agressif, je n'ai à aucun moment prétendu qu'OVH était un super hébergeur.
Pour répondre à votre question, nous avons bel et bien un problème de débit à travers notre tunnel IPSEC qui relie notre infrastructure OVH et notre siège social.
Notre siège social dispose d'une fibre optique Free Pro nouvellement arrivée sur le marché (7Gb/s - 1Gb/s).
Nous cherchons donc à savoir d'où vient la source du problème.
J'ai également ouvert un autre post dans la section approprié "Free Pro" avec les mêmes tests, mais depuis notre siège social.
https://lafibre.info/free-pro/iperf-tcpudp-ovh-lt-gt-free/ (https://lafibre.info/free-pro/iperf-tcpudp-ovh-lt-gt-free/)
Nous avons essayé de résoudre le problème à la source avec le support Free, mais les délais de réponses sont bien trop longs, alors nous essayons de comprendre chaque couches et vérifier s'il n'y aurait pas un problème en amont.
-
Là vous ne testez que Bouygues Telecom <=> OVH.
Bouygues Telecom est connu pour ne pas saturer ses interconnexions, mais des exceptions ou incidents sont possibles.
TCP : (source --> destination = débit)
OVH ROUBAIX --> paris.testdebit.info = 35 Mo/s
OVH ROUBAIX --> lille.testdebit.info = 24 Mo/s
OVH ROUBAIX --> lyon.testdebit.info = 32 Mo/s
OVH ROUBAIX --> aix-marseille.testdebit.info = 19 Mo/s
Les 4 serveurs sont dans une configuration senblable (Ubuntu server 18.04 LTS avec noyau HWE, connexion 10 Gb/s via une carte Intel Ethernet Converged Network Adapters X710 DA-2)
Ce qui change entre ces 4 serveurs, c'est la latence, lié à la vitesse de lumière dans un cœur de silice.
Si le débit est bien le débit en régime établit, cela montre une saturation du nombre de paquets en vol (paquets non acquittés).
Je me demande si une optimisation des buffers sur le machine OVH ne permettrait pas d'être moins dépendant à la latence.
Serait-il possible de connaître le système d'exploitation utilisé coté OVH pour pouvoir donner des conseils ?
Si c'est un Ubuntu / Debian serait il possible de tester après avoir mis ce fichier ?
C'est ce qui est en place sur les serveurs que vous avez testé.
sudo nano /etc/sysctl.d/90-server-optimization.conf
# Reduce the swap
vm.swappiness = 1
# TCP congestion control protocol for high-speed and long-distance networks
net.ipv4.tcp_congestion_control=bbr
# Disable the memorization of previous tests, in order to avoid that the server burns the tests following a limited performance
net.ipv4.tcp_no_metrics_save=1
# Increase TCP buffers
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.core.rmem_max=16777216
net.core.wmem_max=16777216
# Increase the queue within the Linux kernel where traffic is stored after reception from the NIC
net.core.netdev_max_backlog=4000
# Reduce the threshold where a DDOS impacts the server
net.ipv4.tcp_max_syn_backlog = 4096
# Increase number of incoming connections
net.core.somaxconn = 4096
-
Là vous ne testez que Bouygues Telecom <=> OVH.
Bouygues Telecom est connu pour ne pas saturer ses interconnexions, mais des exceptions ou incidents sont possibles.
Les 4 serveurs sont dans une configuration senblable (Ubuntu server 18.04 LTS avec noyau HWE, connexion 10 Gb/s via une carte Intel Ethernet Converged Network Adapters X710 DA-2)
Ce qui change entre ces 4 serveurs, c'est la latence, lié à la vitesse de lumière dans un cœur de silice.
Si le débit est bien le débit en régime établit, cela montre une saturation du nombre de paquets en vol (paquets non acquittés).
Je me demande si une optimisation des buffers sur le machine OVH ne permettrait pas d'être moins dépendant à la latence.
Serait-il possible de connaître le système d'exploitation utilisé coté OVH pour pouvoir donner des conseils ?
Si c'est un Ubuntu / Debian serait il possible de tester après avoir mis ce fichier ?
C'est ce qui est en place sur les serveurs que vous avez testé.
sudo nano /etc/sysctl.d/90-server-optimization.conf
# Reduce the swap
vm.swappiness = 1
# TCP congestion control protocol for high-speed and long-distance networks
net.ipv4.tcp_congestion_control=bbr
# Disable the memorization of previous tests, in order to avoid that the server burns the tests following a limited performance
net.ipv4.tcp_no_metrics_save=1
# Increase TCP buffers
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 87380 16777216
net.core.rmem_max=16777216
net.core.wmem_max=16777216
# Increase the queue within the Linux kernel where traffic is stored after reception from the NIC
net.core.netdev_max_backlog=4000
# Reduce the threshold where a DDOS impacts the server
net.ipv4.tcp_max_syn_backlog = 4096
# Increase number of incoming connections
net.core.somaxconn = 4096
Voici plus d'informations :
Le serveur est en réalité une machine virtuelle Pfsense dans sa dernière version à savoir la 2.5.1. (FreeBSD 12.2-STABLE)
Cette machine virtuelle est hébergée sur ESXi Vmware (6.7.0).
Voici la configuration de l'hôte sur lequel se trouve la VM :
(https://nsa40.casimages.com/img/2021/06/23/210623022836999707.png)
Je peux refaire ces mêmes tests sur une VM Debian 10 si nécessaire.
-
Il pourrait être intéressant de comparer les test avec Linux avant et après avoir passé mes commandes d'optimisation.
-
Il pourrait être intéressant de comparer les test avec Linux avant et après avoir passé mes commandes d'optimisation.
J'ai uniquement refait les tests depuis Debian 10 sans modification à destination de paris.testdebit.info :
UDP : (https://nsa40.casimages.com/img/2021/06/23/21062303030383883.png)
TCP : (https://nsa40.casimages.com/img/2021/06/23/210623030132417862.png)
J'ai plus de débit en TCP qu'en UDP...
Iperf version 3.6
-
Cela serait intéressant de tester le débit descendant également (option -R )
Tu v a voir que c'est pas forcément symétrique...
-
Cela serait intéressant de tester le débit descendant également (option -R )
Tu v a voir que c'est pas forcément symétrique...
Bien sûr, voici :
UDP: (https://nsa40.casimages.com/img/2021/06/23/210623032233530310.png)
TCP: (https://nsa40.casimages.com/img/2021/06/23/210623032233607166.png)
Le TCP est complétement défaillant non?
-
TCP est fortement impacté par les pertes de paquets.
Pour vérifier si il y en a tu transmet des paquets en UDP à un débit largement inférieur au max pour ne pas saturer la connexion (par exemple 100 Mb/s ou moins) et tu regarde si il y a des pertes. 0,1% de perte de paquet c'est énorme pour TCP, il faut vraiment être bien en dessous.
Pour les tests UDP que tu as mis sous Debian, je vois 2,1% de perte de paquet dans le sens upload et 48% dans le sens download. C'est probablement lié à un débit d'émission trop élevé.
-
TCP est fortement impacté par les pertes de paquets.
Pour vérifier si il y en a tu transmet des paquets en UDP à un débit largement inférieur au max pour ne pas saturer la connexion (par exemple 100 Mb/s ou moins) et tu regarde si il y a des pertes. 0,1% de perte de paquet c'est énorme pour TCP, il faut vraiment être bien en dessous.
Pour les tests UDP que tu as mis sous Debian, je vois 2,1% de perte de paquet dans le sens upload et 48% dans le sens download. C'est probablement lié à un débit d'émission trop élevé.
UDP 100Mbit/s :
OVH --> Paris.testdebit.info
(https://nsa40.casimages.com/img/2021/06/23/210623052335831631.png)
Paris.testdebit.info --> OVH
(https://nsa40.casimages.com/img/2021/06/23/210623052335739806.png)
UDP 1000 Mbit/s :
OVH --> Paris.testdebit.info
(https://nsa40.casimages.com/img/2021/06/23/210623052622499361.png)
Paris.testdebit.info --> OVH
(https://nsa40.casimages.com/img/2021/06/23/210623052622587845.png)
Je n'ai pas l'impression qu'il y ai de perte de paquets lorsque les débits sont plus bas.
J'ai refait plusieurs fois chaque test, c'est quasiment tout le temps à 0% de perte à part la première seconde d'envoi.
-
Je suis peut-être à la ramasse mais, j'ai du mal à comprendre.
Comment Pfsense peut avoir des débits TCP à 25 Mo/s et UDP à 270Mo/s et à contrario avoir une VM Debian avec en TCP 600Mo/s et UDP 330 Mo/s.
Iperf à un sacré soucis ou alors je ne comprends rien au réseau..
-
oui y'a des bugs connus avec iperf3, faut toujours utiliser la derniere version (3.9 actuellement).
Faut aussi comparer avec -P 8 ou -P 16 par exemple, certaines OS / logiciels ont une limitation par flux tcp/udp.
-
oui y'a des bugs connus avec iperf3, faut toujours utiliser la derniere version (3.9 actuellement).
Faut aussi comparer avec -P 8 ou -P 16 par exemple, certaines OS / logiciels ont une limitation par flux tcp/udp.
Effectivement deuxième fois que tu me le dis cette semaine Windows et maintenant sous Linux. Désolé ^^
Après avoir mis à jour iperf 3.6 vers 3.9 avec votre tuto :
https://lafibre.info/iperf/installation-iperf-3-9/
Aucun changement :
(https://i.ibb.co/3NbSrR9/iperf-version.png)
P8 :
(https://nsa40.casimages.com/img/2021/06/23/210623062229142013.png)
P16 :
(https://nsa40.casimages.com/img/2021/06/23/21062306222954561.png)
-
Rappel sur le problème initial :
Problème de débit VPN IPSEC entre OVH et Free Pro dans le sens (OVH --> Free) uniquement en TCP.
Etape 1 : Vérification WAN côté d'OVH avec iperf en TCP.
Etape 2 : Vérification WAN côté Free avec iperf en TCP.
Etape 3 : Vérification de la route entre OVH et Free sans IPSEC
Etape 4 : Vérification de la route entre OVH et Free avec IPSEC
Au départ, nous avions commencé par l'étape 4, taille MTU, AES-NI, Blocage des ports ESP / AH / GRE sur la Freebox etc..
Mais nous constatons que le problème existe à moins grande ampleur, mais existe quand même sans tunnel IPSEC.
-
Je n'ai pas l'impression qu'il y ai de perte de paquets lorsque les débits sont plus bas.
J'ai refait plusieurs fois chaque test, c'est quasiment tout le temps à 0% de perte à part la première seconde d'envoi.
Il y a des pertes dans le sens Paris.testdebit.info --> OVH, mais pas dans l'autre sens.
Il faut toujours regarder les pertes sur le récepteur (logique).
Le % de perte me semble anormal, si il est toujours à ce niveau.
-
Il y a des pertes dans le sens Paris.testdebit.info --> OVH, mais pas dans l'autre sens.
Il faut toujours regarder les pertes sur le récepteur (logique).
Le % de perte me semble anormal, si il est toujours à ce niveau.
D'accord, demain je referai ce test avec plus de temps -i (intervalle) et -t (temps) pour avoir une moyenne plus intéressante.
Si vous avez d'autres tests à me faire faire, c'est avec plaisir que je les ferai.
Peut-être qu'il serait plus pertinent de faire les tests iperf directement entre OVH et Free plutôt que séparément ?
(Supprimer étape 1 et 2 et passer à la 3 qui rassemble au final les deux autres) ?
-
Il y a des pertes dans le sens Paris.testdebit.info --> OVH, mais pas dans l'autre sens.
Il faut toujours regarder les pertes sur le récepteur (logique).
Le % de perte me semble anormal, si il est toujours à ce niveau.
Voici 3 tests iperf UDP Paris.testdebit.info --> OVH (100Mb, 500Mb et 1000Mb) :
100Mb :
(https://nsa40.casimages.com/img/2021/06/24/210624101935687056.png)
500Mb :
(https://nsa40.casimages.com/img/2021/06/24/210624102432894805.png)
1000Mb :
(https://nsa40.casimages.com/img/2021/06/24/210624102432796723.png)
Les tests avec -P 8 et -P 16 vous semblent plus fiables pour le TCP?
-
Pas de perte en 100 Mb/s, c'est bon.
Par contre a 500 Mb/s on a de sa saturation.
-
Pas de perte en 100 Mb/s, c'est bon.
Par contre a 500 Mb/s on a de sa saturation.
Je vais faire remonter le problème à OVH.
Concernant le iperf avec -P 8 et -P 16, j'ai l'impression d'obtenir encore plus de débit 1Go/s..
-
Bonjour, je voudrais faire des tests en lignes de commandes sous Win10 avec iperf.
Je suis avec Free 10Gb et installation fibre sur mon LAN, pas de RJ45.
Auriez vous des indications à me donner ?
Merci
-
Bouygues Telecom est connu pour ne pas saturer ses interconnexions, mais des exceptions ou incidents sont possibles.
Aucun incident depuis un bail :)