La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Orange / Sosh => 
Débit fibre => Discussion démarrée par: vivien le 12 août 2024 à 22:12:16
-
Quand un terminal envoi un flux vers internet avec un champ DSCP non nul, à quel endroit ce flux est repassé en DSCP 0 ?
Exemple bête, sous Linux, SSH utilise par défaut un champ DSCP 2 pour le transfert de données type fichier au-dessus de SSH et un autre champ DSCP pour un shell interactif.
(https://lafibre.info/images/orange/202408_transfert_ssh_linux_dscp_0x08.webp)
Il est possible de générer des paquets avec le DSCP de votre choix avec iPerf3 avec -S 0x08
-
Quand un terminal envoi un flux vers internet avec un champ DSCP non nul, à quel endroit ce flux est repassé en DSCP 0 ?
Hello
Pour la PRIO (niveau 2) c'est facile, c'est à l'entré du BNG et partiellement au passage du MSAN (y'a du retag). La PRIO est utilisée sur le segment BNG-LB pour la priorisation (et la limitation) de débit. Utilisation dans le sens montant et descendant.
Pour les règle IP (L3) et le DSCP là je maitrise moins .... :
- y'a plein de règles ARCEP / ARCOM / code PTT sur ce que l'on doit respecter ou pas comme fairness et autres trucs. Et on a une grosse grosse tendance à tout respecter ... ce qui n'est pas toujours simple à mettre en oeuvre
- y'a de la parano à l'entrée du RBCI (donc vis à vis des ORT ou des LB). Je pense que en entrant sur le RBCI venant de ailleurs, on remet à zero tout le DSCP (pas de certitude absolue ici de ma part).
- mais si tu demande un DSCP depuis une LB qui n'est pas priorisé, je ne suis pas certain que l'on touche à quoi que ce soit (là par exemple, je pense pas que l'on ait une différence de traitement entre DSCP 0 et DSCP 8, donc aucune raison de refaire le marquage pour la DSCP8)
- pour rappel, le DSCP c'est un flag qui coté opérateur sera mis dans une classe de service ou l'autre.
- le remarquage du DSCP sortant du RBCI vers d'autres opérateurs ou hébergeur, c'est à la charge du partenaire d'appliquer sa politique de remarquage.
Cela pourrait expliquer que un iperf avec un DSCP à 8 arrive bien jusqu'a une destination chez un autre hébergeur que Orange par exemple.
Le DSCP c'est pas mieux que les politique de MTU dans les backbones : complexe à définir, complexe à mettre en oeuvre, complexe à faire évoluer, complexe en interco.
LeVieux.
-
- mais si tu demande un DSCP depuis une LB qui n'est pas priorisé, je ne suis pas certain que l'on touche à quoi que ce soit (là par exemple, je pense pas que l'on ait une différence de traitement entre DSCP 0 et DSCP 8, donc aucune raison de refaire le marquage pour la DSCP8)
Si ce n'est pas remis à zéro, cela pourrait expliquer que ce champ DSCP mis en place sur le réseau fixe soit utilisé coté mobile. C'est étonnant de ne pas faire de reset.
Depuis que j'ai déménagé, j'ai une Flybox 5G Home Orange et j'ai mes transferts SSH qui sont limités à exactement 5 Mb/s uniquement avec les clients Orange (testé avec un client Livebox 3 et un client Livebox 4). Je n'ai pas cette limitation quand les serveurs SSH sont hors du réseau Orange.
-
Depuis que j'ai déménagé, j'ai une Flybox 5G Home Orange et j'ai mes transferts SSH qui sont limités à exactement 5 Mb/s uniquement avec les clients Orange (testé avec un client Livebox 3 et un client Livebox 4). Je n'ai pas cette limitation quand les serveurs SSH sont hors du réseau Orange.
Et si tu configures SSH pour utiliser un autre codepoint DSCP, par exemple 0, as-tu toujours cette limitation de débit ?
Il est bien probable que la limitation de débit ne soit pas liée à la valeur du champ DSCP.
Orange retag la priorité 802.1p (Ethernet/VLAN) dans son réseau d'accès, mais je crois qu'ils ne touchent pas, comme semble dire LeVieux, à la valeur DSCP.
Ca serait même contre productif de la changer systématiquement en entrée de leur réseau d'ailleurs : le fait qu'SSH utilise 8 (priority class) au lieu de 0 (best effort) permet aux routeurs de prioriser le trafic SSH, qui est interactif, par rapport au trafic moins sensible à la gigue comme les transferts de fichiers.
-
Depuis que j'ai déménagé, j'ai une Flybox 5G Home Orange et j'ai mes transferts SSH qui sont limités à exactement 5 Mb/s uniquement avec les clients Orange (testé avec un client Livebox 3 et un client Livebox 4). Je n'ai pas cette limitation quand les serveurs SSH sont hors du réseau Orange.
Hello
Ce n'est plus un "legal requirement", mais il faut se souvenir que cela l'a été : les réseau fixe et mobile de Orange ne sont pas considérés comme des réseau du même opérateurs.
Il reste donc pas mal de choses en place avec des frontières bien définie.
La politique DSCP entre les réseaux fix et mobile en fait partie.
Je ne connait pas l'utilisation du DSCP 8 sur le réseau mobile, mais manifestement ils ont une politique de COS associée.
Si cela se trouve on garde le DSCP8 entre Orange Fixe et Mobile, mais venant d'internet au sens large c'est remarqué en DSCP 0.
Honnêtement, pour l'avoir fait, c'est le genre de truc qui rend fou en débug sur des réunions téléphones entre 15 experts de la prod des différents domaines.
Des fois juste pour te rendre comptes que un routeur dans un coin a été oublié dans la refonte des politiques de gestion de flux ... (enfin ça c'était avant les possibilités d'automatisations).
LeVieux
-
Et si tu configures SSH pour utiliser un autre codepoint DSCP, par exemple 0, as-tu toujours cette limitation de débit ?
Il est bien probable que la limitation de débit ne soit pas liée à la valeur du champ DSCP.
J'ai testé ce matin : plus de limite de débit avec un DSCP forcé à 0.
-
Un mois plus tard, je reviens sur le sujet, car cette limitation à 5 Mbit/s est incompréhensible pour moi.
Voici un schéma du réseau. Le problème n'est présent que pour les échanges qui restent sur le réseau Orange. Si c'est un échange vers internet, je n'ai pas de bridage du débit.
(https://lafibre.info/images/orange/202409_5g_debit_limite_5_mbps_avec_flux_dscp_schema.avif)
J'ai analysé 2 situations :
1/ Mettre sur le serveur OpenSSH le fichier de configuration suivant :
/etc/ssh/sshd_config.d/ssh_best_effort.conf
# Ne pas prioriser le trafic SSH émis (best effort)
IPQoS cs0 cs0
2/ Mettre sur le client OpenSSH le fichier de configuration suivant :
/etc/ssh/ssh_config.d/ssh_best_effort.conf
# Ne pas prioriser le trafic SSH émis (best effort)
IPQoS cs0 cs0
Attention c'est dans /etc/ssh/ssh_config.d pour le client et /etc/ssh/sshd_config.d pour le serveur.
On a donc 5 situations : (j'ai fait des captures Wireshark coté client et coté serveur afin d'avoir toutes les informations)
Capture 1 : Client et serveur en configuration par défaut et DSCP non réinitialisé par le réseau ⇒ Débit limité à 5 Mb/s
Capture 2 : Client en configuration par défaut et serveur en configuration qui demande de ne pas prioriser (CS0 CS0) les flux et DSCP non réinitialisé par le réseau ⇒ Débit limité à 5 Mb/s
Capture 3 : Client en configuration qui demande de ne pas prioriser (CS0 CS0) les flux et serveur en configuration par défaut et DSCP non réinitialisé par le réseau ⇒ Débit non limité
Capture 4 : Client et serveur en configuration qui demande de ne pas prioriser (CS0 CS0) les flux et DSCP non réinitialisé par le réseau ⇒ Débit non limité
Capture 1bis : Client et serveur en configuration par défaut et DSCP réinitialisé par le réseau ⇒ Débit non limité
(https://lafibre.info/images/orange/202409_5g_debit_limite_5_mbps_avec_flux_dscp_tableau.webp)
-
Si je comprends bien, ce qui bride le débit, c'est quand le client envoie des acquittements priorisés.
Peu importe que le serveur envoie le trafic avec une priorisation, ce qui est important, c'est que le client envoie les paquets sans priorisation.
J'ai donc regardé les captures sur le serveur qui émet le trafic (le PC connecté à la Livebox FTTH) afin de voir si les acquittements arrivent trop tard (si on bride fortement le débit montant, cela a un impact sur le débit descendant).
Toutefois, les acquittements semblent arriver relativement rapidement :
Capture 1 : Client et serveur en configuration par défaut ⇒ Débit limité à 5 Mb/s
(https://lafibre.info/images/orange/202409_transfert_livebox_vers_flybox5g_capture1.webp)
Zoom sur le début de la connexion :
(https://lafibre.info/images/orange/202409_transfert_livebox_vers_flybox5g_capture1_zoom.webp)
-
Capture 2 : Client en configuration par défaut et serveur en configuration qui demande de ne pas prioriser (CS0 CS0) les flux ⇒ Débit limité à 5 Mb/s
(https://lafibre.info/images/orange/202409_transfert_livebox_vers_flybox5g_capture2.webp)
Zoom sur le début de la connexion :
(https://lafibre.info/images/orange/202409_transfert_livebox_vers_flybox5g_capture2_zoom.webp)
-
Capture 3 : Client en configuration qui demande de ne pas prioriser (CS0 CS0) les flux et serveur en configuration par défaut ⇒ Débit limité à 100 Mb/s
(https://lafibre.info/images/orange/202409_transfert_livebox_vers_flybox5g_capture3.webp)
-
Capture 4 : Client et serveur en configuration qui demande de ne pas prioriser (CS0 CS0) les flux ⇒ Débit limité à 100 Mb/s
Note : c'est moins propre que la capture 3, un pb de saturation 5G ? (en tout cas, on dépasse bien les 5 Mb/s, même si on n'arrive pas à 100 Mb/s)
(https://lafibre.info/images/orange/202409_transfert_livebox_vers_flybox5g_capture4.webp)
-
Voici ce que cela donne au niveau débit, quand on est limité à 5 Mb/s.
C'est une limitation à exactement 5 Mbit/s, très stable dans le temps ;:
(https://lafibre.info/images/orange/202409_5g_debit_limite_5_mbps.webp)
Voici quand on n'a pas cette limitation et qu'on est limité par le port 100 Mb/s Ethernet du PC :
(https://lafibre.info/images/orange/202409_5g_debit_limite_100_mbps.webp)
Je précise que ma box 5G est configuration avec un APN IPv6 only (c'est la configuration usine) et que mes transferts se font en IPv4 et n'utilisent pas DNS64, c'est l'IPv4 littérale qui est utilisée (J'utilise le 464XLAT de la box 5G).
Quand je fais un transfert vers Internet, je n'ai pas de problème, que ce soit en IPv6 ou en IPv4 littérale.
En conclusion, je n'arrive pas à comprendre comment des acquittements envoyés par mon PC connecté à la box 5G avec un DSCP non nul arrivent à limiter le débit dans l'autre sens à 5 Mb/s.
On voit que les paquets priorisés sur le réseau mobile arrivent priorisés sur le réseau FTTH, mais dans le chemin le DSCP a été modifié par un équipement du réseau Orange.
- Acquittement émis avec DSCP 0 sur la box 5G ⇒ arrive avec DSCP 0 sur la box FTTH.
- Acquittement émis avec DSCP 2 sur la box 5G ⇒ arrive avec DSCP 40 sur la box FTTH.
-
c'est peut-être une détection du vowifi, les acks prio indique de prio ce traffic entrant (c'est souvent du conntracking donc faisable) ? on ne peut pas se fier forcement au marquage entrant.
dscp 40 c'est pour de téléphonie en pratique non ?
Du coup si on priorise les acks en sortie, on a 5Mbs max en entrée mais prioritaire sur tout le reste ce qui une pratique pour la téléphonie.
si tu fais en meme temps un/des flux qui sature(nt) le lien, est-ce que ton flux limité a 5Mbps baisse ?
-
Quand je fais un nPerf en parallèle (le transfert à 5 Mb/s via un 1er PC connecté directement à la box en 100 Mb/s Ethernet, le nPerf via un second PC connecté en Wi-Fi 6 à la box) je vois que le transfert à 5 Mb/s fluctue.
Il ne serait donc pas priorisé.
Le test de débit :
(https://lafibre.info/images/orange_debit/202409_5g_debit_limite_5_mbps_nperf_1.webp)
L'impact sur le transfert : (j'ai tenté de positionner le test descendant qui dure 15 secondes et le test montant, lui aussi de 15 secondes, avec un certain temps entre les deux pour fermer la connexion et ouvrir celle montant). Les baisses de débit du transfert ont ensuites provoquées des burst qui ont un peu dépassé 5 Mb/s.
(https://lafibre.info/images/orange_debit/202409_5g_debit_limite_5_mbps_nperf_2.webp)
(https://lafibre.info/images/orange_debit/202409_5g_debit_limite_5_mbps_nperf_3.webp)
-
J'ai testé un upload : Je ne suis pas bridé, alors que les paquets envoyés sont bien tagués par DSCP coté client et coté serveur !
J'ai du mal à comprendre.
Commande pour faire un téléchargement : (téléchargement d'un fichier existant de 100Mo situé sur le PC qui fait tourner OpenSSH server dans mon /tmp je suis limité à 5 Mb/s)
scp -P 22 user@pc:/home/user/100M.iso /tmp/
Je suis également bridé à 5 Mb/s avec sftp :
sftp -P 22 user@pc:/home/user/100M.iso /tmp/
Commande pour faire un envoi de fichier : (envoi d'un fichier de 50Mo dans le /tmp du PC avec OpenSSH server - pas de limite de débit)
scp -P 22 /home/user/50M.iso user@pc:/tmp/
Dans les 2 cas, les commandes scp sont passées depuis mon PC qui est connecté à ma box 5G Orange.
Il n'est pas possible d'inverser les rôles serveur / client, car il est impossible d'ouvrir des ports sur la box 5G, que cela soit en IPv4 ou IPv6 (comme sur un mobile en fait). OpenSSH server est donc toujours derrière une Livebox FTTH.
Autre point important : quand l'échange est fait avec internet, je n'ai pas de limitation. Je me demande si la limitaiton de débit en serait pas coté réseau FTTH (si c'était coté réseau mobile, je serais également bridé pour les téléchargement scp sur internet, non ?)
-
La limitation à 5 Mb/s est également présente sur un mobile Orange en partage de connexion (en 4G et 5G Orange).
(https://lafibre.info/images/orange/202409_5g_debit_limite_5_mbps_avec_flux_dscp_schema_2.avif)
J'ai tenté depuis un PC Ubuntu connecté sur mon Google Pixel 6, lui-même sur le réseau 5G Orange et j'ai eu la limitation (la limitation à 5 Mb/s est également présente en 4G).
Pur lever la limitation, il suffit de créer un fichier qui va demander d'utiliser CS0 pour les sessions interactives et CS0 pour les sessions non interactives :
sudo nano /etc/ssh/ssh_config.d/ssh_best_effort.conf
Copier-coller le code ci-dessous
# Ne pas prioriser le trafic SSH émis (best effort)
IPQoS cs0 cs0Pas besoin de redémarrer le PC, c'est effectif lors de la prochaine commande scp / sftp / rsync -e "ssh".
-
Etrange tout de même cette différentiation en fonction de la CoS IP sur le réseau mobile.
Le traffic VoLTE et la signalisation IMS passent dans un PDP différent, et je suis quasiment certain que ce PDP vers l'IMS a une priorité plus haute que ce qui passe par le PDP "orange", qui n'a pour vocation que de transporter du traffic de/vers internet.
Merci pour tes recherches et mesures en tout cas.
-
Je constate un problème un peu similaire, avec également un shaping à 5 Mbit/s mais entre deux FTTH Orange.
Voilà la situation :
- FTTH Orange 1 avec Livebox
- FTTH Orange 2 avec un routeur Mikrotik (pas de Livebox)
- Tunnel Wireguard entre deux machines, l'une derrière Orange 1, l'autre derrière Orange 2
A travers le tunnel Wireguard, j'observe du shaping à 5 Mbit/s dans le sens Orange 1 vers Orange 2. Pas de problème particulier dans l'autre sens.
En envoyant du trafic en direct de Orange 1 à Orange 2 sans tunnel Wireguard, pas de shaping constaté. Et entre des serveurs extérieurs et Orange 1 / Orange 2, aucun shaping non plus.
Le truc bizarre par rapport à ce que tu as pu observer, c'est qu'ici il n'y a pas de champ DSCP configuré. On a vérifié les règles QoS sur le Mikrotik (pour le DHCP), a priori elles ne s'appliquent pas au trafic Wireguard.
-
Si tu passes la MTU des interfaces wireguard à 1400 voire 1300 bytes, juste le temps des tests, ca change quelque chose ?
Si ton tunnel est transporté en IPv4, peux-tu tenter en IPv6?
-
Si les 2 PC sont sous Linux, pourrais-tu tester un transfert de fichier via OpenSSH ?
Pour ma part, une simple ligne de commande ci-dessous permet de mettre en évidence la limitation à 5 Mb/s :
Commande pour faire un téléchargement : (téléchargement d'un fichier existant de 100Mo situé sur le PC qui fait tourner OpenSSH server dans mon /tmp je suis limité à 5 Mb/s)
scp -P 22 user@pc:/home/user/100M.iso /tmp/
Je suis également bridé à 5 Mb/s avec sftp :
sftp -P 22 user@pc:/home/user/100M.iso /tmp/
Attention, la limitation de débit n'est pas systématique, mais elle intervient régulièrement (je n'ai pas trouvé la cause, ce n'est pas lié à un changement d'IP).
-
Pour la MTU, les interfaces wireguard sont déjà à 1340, ça donne des paquets IP de 1400 après encapsulation.
Pour le scp en direct (hors tunnel), il n'y a pas de limitation.
Par contre ça m'a mis sur la piste d'un truc bizarre : mes paquets Wireguard sont émis côté serveur Orange 1 avec un tos à 0x0, mais de l'autre côté ils sont reçu avec un tos 0x88 !
Paquet émis :
11:25:58.764226 IP (tos 0x0, ttl 64, id 48444, offset 0, flags [none], proto UDP (17), length 1400)
192.168.5.120.50015 > XX.XX.XX.XX.50051: UDP, length 1372
Paquet reçu :
11:25:58.769620 IP (tos 0x88, ttl 60, id 46870, offset 0, flags [none], proto UDP (17), length 1400)
YY.YY.YY.YY.50015 > 192.168.42.26.50051: [udp sum ok] UDP, length 1372
Si je lis bien 0x88 c'est la classe de QoS AF41, "Multimedia Conferencing". Je suspecte que ce soit la livebox source qui mette ce champ...
-
Attention, la limitation de débit n'est pas systématique, mais elle intervient régulièrement (je n'ai pas trouvé la cause, ce n'est pas lié à un changement d'IP).
Dans mon cas, ce n'est pas apparu tout de suite, mais depuis ça fait une semaine en continu que le shaping est en place :
- le tunnel a été mis en place le 12 février
- au début, il n'y avait pas de limitation de débit
- le shaping a été constaté le 16 février (potentiellement suite à un reboot de la Livebox côté Orange 1)
- depuis, le shaping est présent en continu, malgré des reboots de la Livebox côté Orange 1 (ça fait une semaine)
-
On est donc sur le même problème, vu le débit similaire et la présence de flux tagué (DSCP / TOS différent de 0).
Le problème ne serait pas sur le réseau mobile comme je le pensais au début, mais sur le réseau FTTH ?
Ce qui est étrange, c'est que le même flux n'est pas limité vers internet (je ne sais pas si tu peux confirmer). Pour moi la seule limitation est vers le réseau Orange. Avant de déménager et de prendre une box 5G Orange, je n'avais aucun problème pour le même transfert, étant sur une box FTTH SFR (et des PC que je sauvegarde sont des PC Linux qui sont derrière des Livebox 3 et 4). Je n'ai pas non plus de problème quand j'utilise ma box pour des transferts vers Internet. Le problème ne se produit que quand on reste sur le réseau Orange.
Pour mon problème, c'est bien le DSCP qui crée le bridage, il suffit de rajouter cette ligne coté client pour ne plus avoir le flux tagué et ne plus avoir de limitation de débit :
2/ Mettre sur le client OpenSSH le fichier de configuration suivant :
/etc/ssh/ssh_config.d/ssh_best_effort.conf
# Ne pas prioriser le trafic SSH émis (best effort)
IPQoS cs0 cs0
Dans ton cas, pourrais-tu donner plus de détails :
- Quelle est la Livebox utilisée ? Si c'est une box avec un ONT externe, pourrais-tu mettre un PC en bridege pour voir si c'est la box qui change les flux DSCP / TOS ?
- As-tu le problème avec tunnel Wireguard hors du réseau Orange ?
- Si tu as un mobile Orange / SOSH pourais tu faire des tests pour voir si la limitation est bien présente ? (dans mon cas, j'ai observé le pb sur ma box 5G, mais après, j'ai vu que c'était également le cas avec mon smartphone SOSH en partage de connexion)
-
Je te rejoins sur le côté bizarre que ça se limite à Orange-Orange. Je n'ai jamais constaté de problème entre ce FTTH Orange et d'autres destinations. J'ai pourtant plusieurs tunnels Wireguard vers différents FAI qui sont utilisés depuis des années.
Une différence possible, c'est que sur ce nouveau tunnel je fais passer des gros bursts de trafic (synchro ZFS qui copie quelques GB toutes les heures), ce que je ne faisais pas sur les autres tunnels. Ca a peut-être déclenché un mécanisme anti-DDoS ou quelque chose du genre.
Le plus bizarre, c'est que les deux FTTH Orange qui ont le problème sont sur le même NRO. Sur un traceroute, il y a un seul hop IP entre les deux, et une latence de 2-3 ms. Donc le shaping est vraiment fait
localement (soit par la box, soit par un équipement au NRO, soit sur un point de routage local du réseau Orange).
Pour les précisions :
- Quelle est la Livebox utilisée ? Une Livebox 5, donc avec ONT intégré, pas possible de faire une capture après la box
- As-tu le problème avec tunnel Wireguard hors du réseau Orange ? Non absolument pas
- Si tu as un mobile Orange / SOSH : Non, désolé
-
Si c'est bien la Livebox, ca ferait penser à une ALG ou quelque chose comme cela. Tu peux aussi essayer d'autres ports UDP et/ou en IPv6.
-
+1 pour les autres ports, voir si c'est aussi taggé ou réapparaît plus tard. Et si c'est la box elle même qui tague, essayer de la reset ?
Chez moi, j'ai du WG site-to-site derrière 2 ADSL orange, mais avec routeur perso : pas de tag bizarre, ni avec mon smartphone chez sosh, connecté au même serveur.
-
Chez moi, j'ai du WG site-to-site derrière 2 ADSL orange, mais avec routeur perso : pas de tag bizarre, ni avec mon smartphone chez sosh, connecté au même serveur.
Je peux aussi confirmer qu'entre deux FTTH Orange je ne vois pas de tag particulier ni de problème de débit (je tape les 400Mbit/s sans souci). Un côté est une Livebox 5, l'autre est un routeur tiers OpenWRT.
C'est en IPv6 par contre, donc on ne traverse pas les ALG et le NAT, à priori.
-
Depuis une machine chez moi, derrière une Livebox 5 fournie à l'occasion d'un contrat Sosh Fibre, à destination d'une machine virtuelle que j'administre, hébergée par Tetaneutral. IPv4 : pas de limite curieuse. IPv6 : 5,0 Mbit/s, point à la ligne. Vu de l'abonné que je suis, c'est le sens upload vers une machine sur internet.
<troll>Apparement, tous les paquets ne naissent pas égaux en droits au yeux d'un grozopérateur sur le chemin.</troll>
Je soupçonne que ça date, mais je n'ai regardé de plus près qu'il y a quelques matins de ça car un backup un matin a pris beaucoup de temps. Je viens de refaire des mtr et des iperf3 ce matin pour poster ici, les résultats n'ont pas varié.
Côté source : j'ai essayé avec un Dell 5490 et avec un Intel NUC 12ème génération, mêmes résultats.
Côté destination : Grâce aux amis admins de l'asso, on a pu vérifier que à destination d'autres machines chez eux, ça le fait toujours.
Côté routes / opérateurs intermédiaires : on a pu vérifier aussi que via EuroFiber, via Cogent, via Hurricane Electrics : même résultat 5,0 Mbit/s en IPv6
Un second abonné Sosh ami de Tetaneutral a constaté aussi ce problème vers le réseau Tetaneutral.
On a pas mal testé d'autres destinations (OVH, renater, ...) et il n'y a que orange ipv6 upload vers Tetaneutral qui pose problème.
On a tenté de mettre un socat au bout d'une connexion OVH fibre pour que le chemin chez moi -> pouzenc.fr en IPv6 devienne : chez moi -> machine sur une fibre OVH -> pouzenc.fr et le débit IPv6 est supériur à 150Mbit/s comme ça. Si on ne passe plus par cet intermédiaire, pouf 5,0 Mbit/s.
Je cherche à savoir si d'autres personnes constatent aussi ce genre de valeur, et sur quelle paire source-destination.
IPv4
lpouzenc@lud-5490:~$ mtr -bzwe4 pouzenc.fr
Start: 2025-07-28T12:20:58+0200
HOST: lud-5490 Loss% Snt Last Avg Best Wrst StDev
1. AS??? livebox.home (192.168.1.1) 0.0% 10 3.1 3.7 3.0 5.7 0.8
2. AS??? 80.10.253.173 0.0% 10 4.2 6.5 4.2 18.0 4.2
3. AS??? ae109-0.ncgre101.rbci.orange.net (193.253.87.206) 0.0% 10 6.6 8.5 6.3 13.4 2.6
4. AS??? ae43-0.nilyo101.rbci.orange.net (193.252.101.129) 0.0% 10 8.8 9.2 8.2 12.3 1.2
5. AS??? ae40-0.nilyo102.rbci.orange.net (193.252.101.174) 0.0% 10 9.2 8.8 8.6 9.2 0.2
[MPLS: Lbl 11972 TC 0 S u TTL 1]
6. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
7. AS5511 193.251.133.84 40.0% 10 14.8 14.7 14.3 14.9 0.2
8. AS5511 193.251.254.104 0.0% 10 17.8 17.7 15.6 24.5 2.5
9. AS35625 th2.ibr-idf-1.as35625.net (45.15.206.106) 0.0% 10 25.3 24.8 23.4 27.5 1.3
[MPLS: Lbl 24010 TC 0 S u TTL 1]
10. AS35625 45.15.206.111 0.0% 10 25.4 25.1 23.8 26.9 0.9
[MPLS: Lbl 24000 TC 0 S u TTL 1]
11. AS35625 45.15.206.121 0.0% 10 23.5 23.7 22.9 26.1 1.1
12. AS174 149.11.58.74 0.0% 10 24.6 24.2 23.7 25.5 0.6
13. AS197422 mail.pouzenc.fr (91.224.149.159) 0.0% 10 24.1 25.1 23.8 29.5 1.8
lpouzenc@lud-5490:~$ iperf3 -4 -c pouzenc.fr
Connecting to host pouzenc.fr, port 5201
[ 5] local 192.168.1.149 port 36872 connected to 91.224.149.159 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 17.9 MBytes 150 Mbits/sec 0 926 KBytes
[ 5] 1.00-2.00 sec 37.5 MBytes 315 Mbits/sec 0 1.97 MBytes
[ 5] 2.00-3.00 sec 37.5 MBytes 315 Mbits/sec 0 2.42 MBytes
[ 5] 3.00-4.00 sec 40.0 MBytes 336 Mbits/sec 0 2.60 MBytes
[ 5] 4.00-5.00 sec 38.8 MBytes 325 Mbits/sec 0 2.75 MBytes
[ 5] 5.00-6.00 sec 38.8 MBytes 325 Mbits/sec 0 2.90 MBytes
[ 5] 6.00-7.00 sec 38.8 MBytes 325 Mbits/sec 0 3.06 MBytes
[ 5] 7.00-8.00 sec 38.8 MBytes 325 Mbits/sec 0 3.06 MBytes
[ 5] 8.00-9.00 sec 40.0 MBytes 336 Mbits/sec 0 3.06 MBytes
[ 5] 9.00-10.00 sec 40.0 MBytes 336 Mbits/sec 0 3.06 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 368 MBytes 309 Mbits/sec 0 sender
[ 5] 0.00-10.03 sec 366 MBytes 306 Mbits/sec receiver
iperf Done.
Sortie iperf côté serveur pouzenc.fr :
iperf 3.12
Linux piou 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Time: Mon, 28 Jul 2025 10:23:08 GMT
Accepted connection from 2.7.154.171, port 36866
Cookie: p5u3vbxkes6cilatag2l5rc473gbw4mzjpzr
TCP MSS: 0 (default)
[ 5] local 91.224.149.159 port 5201 connected to 2.7.154.171 port 36872
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 14.8 MBytes 124 Mbits/sec
[ 5] 1.00-2.00 sec 37.4 MBytes 313 Mbits/sec
[ 5] 2.00-3.00 sec 37.6 MBytes 315 Mbits/sec
[ 5] 3.00-4.00 sec 39.7 MBytes 333 Mbits/sec
[ 5] 4.00-5.00 sec 38.9 MBytes 326 Mbits/sec
[ 5] 5.00-6.00 sec 38.9 MBytes 326 Mbits/sec
[ 5] 6.00-7.00 sec 38.1 MBytes 319 Mbits/sec
[ 5] 7.00-8.00 sec 39.7 MBytes 333 Mbits/sec
[ 5] 8.00-9.00 sec 39.8 MBytes 334 Mbits/sec
[ 5] 9.00-10.00 sec 39.9 MBytes 334 Mbits/sec
[ 5] 10.00-10.03 sec 1.39 MBytes 410 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate
[ 5] (sender statistics not available)
[ 5] 0.00-10.03 sec 366 MBytes 306 Mbits/sec receiver
rcv_tcp_congestion cubic
lpouzenc@lud-5490:~$ iperf3 -4 -u -b20M -c pouzenc.fr
Connecting to host pouzenc.fr, port 5201
[ 5] local 192.168.1.149 port 36014 connected to 91.224.149.159 port 5201
[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 2.38 MBytes 20.0 Mbits/sec 1726
[ 5] 1.00-2.00 sec 2.38 MBytes 20.0 Mbits/sec 1726
[ 5] 2.00-3.00 sec 2.38 MBytes 20.0 Mbits/sec 1727
[ 5] 3.00-4.00 sec 2.38 MBytes 20.0 Mbits/sec 1726
[ 5] 4.00-5.00 sec 2.38 MBytes 20.0 Mbits/sec 1727
[ 5] 5.00-6.00 sec 2.38 MBytes 20.0 Mbits/sec 1726
[ 5] 6.00-7.00 sec 2.38 MBytes 20.0 Mbits/sec 1727
[ 5] 7.00-8.00 sec 2.38 MBytes 20.0 Mbits/sec 1726
[ 5] 8.00-9.00 sec 2.38 MBytes 20.0 Mbits/sec 1727
[ 5] 9.00-10.00 sec 2.38 MBytes 20.0 Mbits/sec 1727
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 23.8 MBytes 20.0 Mbits/sec 0.000 ms 0/17265 (0%) sender
[ 5] 0.00-10.02 sec 23.8 MBytes 20.0 Mbits/sec 0.234 ms 0/17265 (0%) receiver
iperf Done.
lpouzenc@lud-5490:~$
Sortie iperf côté serveur pouzenc.fr :
iperf 3.12
Linux piou 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64
-----------------------------------------------------------
Server listening on 5201 (test #4)
-----------------------------------------------------------
Time: Mon, 28 Jul 2025 10:24:29 GMT
Accepted connection from 2.7.154.171, port 48440
Cookie: h4fcixr6u3scs2owutgdd7kbm7ioqs77ruu4
Target Bitrate: 20000000
[ 5] local 91.224.149.159 port 5201 connected to 2.7.154.171 port 36014
Starting Test: protocol: UDP, 1 streams, 1448 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 2.33 MBytes 19.5 Mbits/sec 0.390 ms 0/1685 (0%)
[ 5] 1.00-2.00 sec 2.38 MBytes 20.0 Mbits/sec 0.298 ms 0/1727 (0%)
[ 5] 2.00-3.00 sec 2.38 MBytes 20.0 Mbits/sec 0.336 ms 0/1727 (0%)
[ 5] 3.00-4.00 sec 2.38 MBytes 20.0 Mbits/sec 0.345 ms 0/1726 (0%)
[ 5] 4.00-5.00 sec 2.38 MBytes 20.0 Mbits/sec 0.319 ms 0/1727 (0%)
[ 5] 5.00-6.00 sec 2.38 MBytes 20.0 Mbits/sec 0.334 ms 0/1726 (0%)
[ 5] 6.00-7.00 sec 2.38 MBytes 20.0 Mbits/sec 0.377 ms 0/1727 (0%)
[ 5] 7.00-8.00 sec 2.38 MBytes 20.0 Mbits/sec 0.427 ms 0/1725 (0%)
[ 5] 8.00-9.00 sec 2.39 MBytes 20.0 Mbits/sec 0.339 ms 0/1728 (0%)
[ 5] 9.00-10.00 sec 2.38 MBytes 20.0 Mbits/sec 0.289 ms 0/1727 (0%)
[ 5] 10.00-10.02 sec 56.6 KBytes 20.0 Mbits/sec 0.234 ms 0/40 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] (sender statistics not available)
[ 5] 0.00-10.02 sec 23.8 MBytes 20.0 Mbits/sec 0.234 ms 0/17265 (0%) receiver
IPv6
lpouzenc@lud-5490:~$ mtr -bzwe6 pouzenc.fr
Start: 2025-07-28T12:22:13+0200
HOST: lud-5490 Loss% Snt Last Avg Best Wrst StDev
1. AS3215 livebox.home (2a01:cb15:85b0:7d00:12e9:92ff:fe6b:8af0) 0.0% 10 5.0 6.2 4.7 9.7 1.8
2. AS3215 2a01cb08a004020a0193025300750246.ipv6.abo.wanadoo.fr (2a01:cb08:a004:20a:193:253:75:246) 0.0% 10 6.2 6.7 5.2 10.5 1.4
3. AS??? 2a01:cfc0:200:8000:193:252:102:31 0.0% 10 9.9 9.9 9.0 10.5 0.4
[MPLS: Lbl 2 TC 0 S u TTL 1]
4. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6. AS197422 mail.pouzenc.fr (2a03:7220:8081:9f00::1) 0.0% 10 25.0 24.9 23.5 26.0 0.7
lpouzenc@lud-5490:~$ iperf3 -6 -c pouzenc.fr
Connecting to host pouzenc.fr, port 5201
[ 5] local 2a01:cb15:85b0:7d00:302a:4010:e8f3:60dc port 57596 connected to 2a03:7220:8081:9f00::1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 860 KBytes 7.05 Mbits/sec 10 43.2 KBytes
[ 5] 1.00-2.00 sec 628 KBytes 5.14 Mbits/sec 0 51.6 KBytes
[ 5] 2.00-3.00 sec 628 KBytes 5.14 Mbits/sec 0 58.6 KBytes
[ 5] 3.00-4.00 sec 628 KBytes 5.14 Mbits/sec 0 66.9 KBytes
[ 5] 4.00-5.00 sec 565 KBytes 4.63 Mbits/sec 0 72.5 KBytes
[ 5] 5.00-6.00 sec 753 KBytes 6.17 Mbits/sec 0 79.5 KBytes
[ 5] 6.00-7.00 sec 565 KBytes 4.63 Mbits/sec 0 85.1 KBytes
[ 5] 7.00-8.00 sec 628 KBytes 5.14 Mbits/sec 0 107 KBytes
[ 5] 8.00-9.00 sec 879 KBytes 7.20 Mbits/sec 0 149 KBytes
[ 5] 9.00-10.00 sec 816 KBytes 6.68 Mbits/sec 0 208 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 6.78 MBytes 5.69 Mbits/sec 10 sender
[ 5] 0.00-10.34 sec 6.10 MBytes 4.95 Mbits/sec receiver
iperf Done.
Sortie iperf côté serveur pouzenc.fr :
iperf 3.12
Linux piou 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64
-----------------------------------------------------------
Server listening on 5201 (test #2)
-----------------------------------------------------------
Time: Mon, 28 Jul 2025 10:23:22 GMT
Accepted connection from 2a01:cb15:85b0:7d00:302a:4010:e8f3:60dc, port 57586
Cookie: gsgy3m3qpu6d2vai2oekiln6bpbb4wxer6ry
TCP MSS: 0 (default)
[ 5] local 2a03:7220:8081:9f00::1 port 5201 connected to 2a01:cb15:85b0:7d00:302a:4010:e8f3:60dc port 57596
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 604 KBytes 4.95 Mbits/sec
[ 5] 1.00-2.00 sec 604 KBytes 4.95 Mbits/sec
[ 5] 2.00-3.00 sec 605 KBytes 4.96 Mbits/sec
[ 5] 3.00-4.00 sec 604 KBytes 4.95 Mbits/sec
[ 5] 4.00-5.00 sec 604 KBytes 4.95 Mbits/sec
[ 5] 5.00-6.00 sec 605 KBytes 4.96 Mbits/sec
[ 5] 6.00-7.00 sec 605 KBytes 4.96 Mbits/sec
[ 5] 7.00-8.00 sec 604 KBytes 4.95 Mbits/sec
[ 5] 8.00-9.00 sec 605 KBytes 4.96 Mbits/sec
[ 5] 9.00-10.00 sec 604 KBytes 4.95 Mbits/sec
[ 5] 10.00-10.34 sec 206 KBytes 4.93 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate
[ 5] (sender statistics not available)
[ 5] 0.00-10.34 sec 6.10 MBytes 4.95 Mbits/sec receiver
rcv_tcp_congestion cubic
lpouzenc@lud-5490:~$ iperf3 -6 -u -b20M -c pouzenc.fr
Connecting to host pouzenc.fr, port 5201
[ 5] local 2a01:cb15:85b0:7d00:302a:4010:e8f3:60dc port 56463 connected to 2a03:7220:8081:9f00::1 port 5201
[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 2.38 MBytes 20.0 Mbits/sec 1750
[ 5] 1.00-2.00 sec 2.38 MBytes 20.0 Mbits/sec 1750
[ 5] 2.00-3.00 sec 2.38 MBytes 20.0 Mbits/sec 1751
[ 5] 3.00-4.00 sec 2.38 MBytes 20.0 Mbits/sec 1751
[ 5] 4.00-5.00 sec 2.38 MBytes 20.0 Mbits/sec 1750
[ 5] 5.00-6.00 sec 2.38 MBytes 20.0 Mbits/sec 1751
[ 5] 6.00-7.00 sec 2.38 MBytes 20.0 Mbits/sec 1751
[ 5] 7.00-8.00 sec 2.38 MBytes 20.0 Mbits/sec 1751
[ 5] 8.00-9.00 sec 2.38 MBytes 20.0 Mbits/sec 1750
[ 5] 9.00-10.00 sec 2.38 MBytes 20.0 Mbits/sec 1751
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 23.8 MBytes 20.0 Mbits/sec 0.000 ms 0/17506 (0%) sender
[ 5] 0.00-12.36 sec 7.45 MBytes 5.06 Mbits/sec 0.462 ms 12030/17502 (69%) receiver
iperf Done.
Sortie iperf côté serveur pouzenc.fr :
-----------------------------------------------------------
Server listening on 5201 (test #3)
-----------------------------------------------------------
Time: Mon, 28 Jul 2025 10:23:43 GMT
Accepted connection from 2a01:cb15:85b0:7d00:302a:4010:e8f3:60dc, port 58448
Cookie: 7sr4jsmqlvtarcwz3u27ckzb2nsz4o7tcus6
Target Bitrate: 20000000
[ 5] local 2a03:7220:8081:9f00::1 port 5201 connected to 2a01:cb15:85b0:7d00:302a:4010:e8f3:60dc port 56463
Starting Test: protocol: UDP, 1 streams, 1428 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 655 KBytes 5.37 Mbits/sec 1.685 ms 69/539 (13%)
[ 5] 1.00-2.00 sec 615 KBytes 5.04 Mbits/sec 1.658 ms 0/441 (0%)
[ 5] 2.00-3.00 sec 614 KBytes 5.03 Mbits/sec 1.683 ms 0/440 (0%)
[ 5] 3.00-4.00 sec 614 KBytes 5.03 Mbits/sec 0.498 ms 1009/1449 (70%)
[ 5] 4.00-5.00 sec 615 KBytes 5.04 Mbits/sec 0.541 ms 1313/1754 (75%)
[ 5] 5.00-6.00 sec 614 KBytes 5.03 Mbits/sec 0.456 ms 1308/1748 (75%)
[ 5] 6.00-7.00 sec 614 KBytes 5.03 Mbits/sec 0.712 ms 1310/1750 (75%)
[ 5] 7.00-8.00 sec 615 KBytes 5.04 Mbits/sec 0.448 ms 1315/1756 (75%)
[ 5] 8.00-9.00 sec 614 KBytes 5.03 Mbits/sec 0.816 ms 1306/1746 (75%)
[ 5] 9.00-10.00 sec 615 KBytes 5.04 Mbits/sec 0.519 ms 1311/1752 (75%)
[ 5] 10.00-11.00 sec 614 KBytes 5.03 Mbits/sec 0.495 ms 1309/1749 (75%)
[ 5] 11.00-12.00 sec 614 KBytes 5.03 Mbits/sec 0.441 ms 1309/1749 (75%)
[ 5] 12.00-12.36 sec 220 KBytes 5.03 Mbits/sec 0.462 ms 471/629 (75%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] (sender statistics not available)
[ 5] 0.00-12.36 sec 7.45 MBytes 5.06 Mbits/sec 0.462 ms 12030/17502 (69%) receiver
-
J'ai fusionné ton message avec le sujet dédié.
Client box 5G chez Orange et ayant des échanges avec des Livebox FTTH limité à 5 Mb/s, je pensais que c'était le côté mobile qui bridait, mais c'est visiblement peut-être coté FTTH.
Je suis preneur de plus de détails, notamment sur les champs DSCP de tes paquets.
Chez moi le fait de mettre IPQoS cs0 cs0 coté machine qui reçoit le trafic permet de lever la limittation :
Optionnel : Déprioriser le trafic de la sauvegarde
OpenSSH définit le champ TOS (type de service) dans l'entête IP afin de prioriser avec une faible latence les sessions interactives et de prioriser le débit les sessions non interactives.
Ces priorisations ne fonctionnent pas sur Internet (neutralité d'internet) et ce trafic atypique (SSH est une des rares applications à prioriser son trafic) peut poser un problème à des équipements réseaux.
Par exemple, la sauvegarde d'une Livebox Orange réalisée depuis le réseau mobile d'Orange (testé avec une Flybox 5G) sera limité à 5 Mb/s (afin que n'importe quel trafic ne soit pas priorisé, des limites de débit sont mis en place sur le trafic priorisé).
Il est donc conseillé de ne pas prioriser le trafic (best effort), ce qui correspond à la valeur CS0.
Pour en savoir plus : page Wikipédia Differentiated services (https://fr.wikipedia.org/wiki/Differentiated_services).
1/ Coté machine sauvegardée, pour déprioriser le trafic émis par ce PC (contenu de la sauvegarde) :
On crée un fichier qui va demander d'utiliser CS0 pour les sessions interactives et CS0 pour les sessions non interactives :
sudo nano /etc/sshd/ssh_config.d/ssh_best_effort.conf
Copier-coller le code ci-dessous
# Ne pas prioriser le trafic SSH émis (best effort)
IPQoS cs0 cs0
2/ Coté PC avec le script de sauvegarde, pour déprioriser le trafic émis par ce PC (principalement les acquittements TCP - c'est ce trafic qui pose un problème avec le box 5G Orange)
On crée un fichier qui va demander d'utiliser CS0 pour les sessions interactives et CS0 pour les sessions non interactives :
sudo nano /etc/ssh/ssh_config.d/ssh_best_effort.conf
Copier-coller le code ci-dessous
# Ne pas prioriser le trafic SSH émis (best effort)
IPQoS cs0 cs0
Attention, la ligne de commande est presque identique entre les deux côtés, mais il y a une différence : /etc/sshd/ssh_config.d vs /etc/ssh/ssh_config.d
-
J'ai profité du fait que ton serveur écoute sur le port iperf3 pour faire quelques tests depuis une connexion FTTH sosh sans box (routeur OpenWRT):
$ iperf3 -c 2a03:7220:8081:9f00::1
Connecting to host 2a03:7220:8081:9f00::1, port 5201
[ 5] local 2a01:cb08:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 39816 connected to 2a03:7220:8081:9f00::1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 13.8 MBytes 115 Mbits/sec 0 630 KBytes
[ 5] 1.00-2.00 sec 35.0 MBytes 294 Mbits/sec 40 1.44 MBytes
[ 5] 2.00-3.00 sec 33.8 MBytes 283 Mbits/sec 0 1.60 MBytes
[ 5] 3.00-4.00 sec 32.5 MBytes 273 Mbits/sec 0 1.73 MBytes
[ 5] 4.00-5.00 sec 31.2 MBytes 262 Mbits/sec 0 1.83 MBytes
[ 5] 5.00-6.00 sec 35.0 MBytes 293 Mbits/sec 0 1.90 MBytes
[ 5] 6.00-7.00 sec 33.8 MBytes 284 Mbits/sec 133 1.41 MBytes
[ 5] 7.00-8.00 sec 33.8 MBytes 283 Mbits/sec 0 1.49 MBytes
[ 5] 8.00-9.00 sec 33.8 MBytes 283 Mbits/sec 0 1.54 MBytes
[ 5] 9.00-10.00 sec 33.8 MBytes 283 Mbits/sec 0 1.58 MBytes
[ 5] 10.00-11.00 sec 32.5 MBytes 273 Mbits/sec 0 1.61 MBytes
[ 5] 11.00-12.00 sec 31.2 MBytes 262 Mbits/sec 0 1.62 MBytes
[ 5] 12.00-13.00 sec 27.5 MBytes 231 Mbits/sec 0 1.62 MBytes
^C[ 5] 13.00-13.83 sec 27.5 MBytes 277 Mbits/sec 0 1.62 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-13.83 sec 435 MBytes 264 Mbits/sec 173 sender
[ 5] 0.00-13.83 sec 0.00 Bytes 0.00 bits/sec receiver
iperf3: interrupt - the client has terminated
$ iperf3 -c 2a03:7220:8081:9f00::1 -t 120 --reverse
Connecting to host 2a03:7220:8081:9f00::1, port 5201
Reverse mode, remote host 2a03:7220:8081:9f00::1 is sending
[ 5] local 2a01:cb08:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 43476 connected to 2a03:7220:8081:9f00::1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 23.6 MBytes 198 Mbits/sec
[ 5] 1.00-2.00 sec 30.9 MBytes 259 Mbits/sec
[ 5] 2.00-3.00 sec 29.5 MBytes 248 Mbits/sec
[ 5] 3.00-4.00 sec 29.5 MBytes 247 Mbits/sec
[ 5] 4.00-5.00 sec 26.4 MBytes 221 Mbits/sec
[ 5] 5.00-6.00 sec 27.5 MBytes 231 Mbits/sec
[ 5] 6.00-7.00 sec 28.9 MBytes 242 Mbits/sec
[ 5] 7.00-8.00 sec 26.4 MBytes 222 Mbits/sec
[ 5] 8.00-9.00 sec 28.7 MBytes 241 Mbits/sec
[ 5] 9.00-10.00 sec 27.8 MBytes 233 Mbits/sec
[ 5] 10.00-11.00 sec 25.5 MBytes 214 Mbits/sec
[ 5] 11.00-12.00 sec 28.5 MBytes 239 Mbits/sec
[ 5] 12.00-13.00 sec 28.9 MBytes 242 Mbits/sec
[ 5] 13.00-14.00 sec 28.8 MBytes 242 Mbits/sec
^C[ 5] 14.00-14.39 sec 12.5 MBytes 270 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-14.39 sec 0.00 Bytes 0.00 bits/sec sender
[ 5] 0.00-14.39 sec 403 MBytes 235 Mbits/sec receiver
iperf3: interrupt - the client has terminated
$ iperf3 -c 64:ff9b::91.224.149.159
Connecting to host 64:ff9b::91.224.149.159, port 5201
[ 5] local 2a01:cb08:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 55624 connected to 64:ff9b::5be0:959f port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 3.58 MBytes 30.1 Mbits/sec 0 187 KBytes
[ 5] 1.00-2.00 sec 2.70 MBytes 22.6 Mbits/sec 0 237 KBytes
[ 5] 2.00-3.00 sec 2.70 MBytes 22.6 Mbits/sec 0 266 KBytes
[ 5] 3.00-4.00 sec 2.76 MBytes 23.1 Mbits/sec 0 266 KBytes
[ 5] 4.00-5.00 sec 2.94 MBytes 24.7 Mbits/sec 0 301 KBytes
[ 5] 5.00-6.00 sec 2.70 MBytes 22.6 Mbits/sec 0 342 KBytes
[ 5] 6.00-7.00 sec 3.06 MBytes 25.7 Mbits/sec 0 381 KBytes
[ 5] 7.00-8.00 sec 2.51 MBytes 21.1 Mbits/sec 0 431 KBytes
[ 5] 8.00-9.00 sec 2.76 MBytes 23.1 Mbits/sec 0 516 KBytes
[ 5] 9.00-10.00 sec 3.29 MBytes 27.6 Mbits/sec 0 586 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 29.0 MBytes 24.3 Mbits/sec 0 sender
[ 5] 0.00-10.10 sec 26.9 MBytes 22.3 Mbits/sec receiver
iperf Done.
$ iperf3 -c 64:ff9b::91.224.149.159 --reverse
Connecting to host 64:ff9b::91.224.149.159, port 5201
Reverse mode, remote host 64:ff9b::91.224.149.159 is sending
[ 5] local 2a01:cb08:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 45650 connected to 64:ff9b::5be0:959f port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 2.55 MBytes 21.4 Mbits/sec
[ 5] 1.00-2.00 sec 2.70 MBytes 22.6 Mbits/sec
[ 5] 2.00-3.00 sec 2.69 MBytes 22.6 Mbits/sec
[ 5] 3.00-4.00 sec 2.70 MBytes 22.6 Mbits/sec
[ 5] 4.00-5.00 sec 2.56 MBytes 21.5 Mbits/sec
[ 5] 5.00-6.00 sec 2.81 MBytes 23.6 Mbits/sec
[ 5] 6.00-7.00 sec 2.69 MBytes 22.6 Mbits/sec
[ 5] 7.00-8.00 sec 2.70 MBytes 22.6 Mbits/sec
[ 5] 8.00-9.00 sec 2.69 MBytes 22.6 Mbits/sec
[ 5] 9.00-10.00 sec 2.64 MBytes 22.1 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.11 sec 30.0 MBytes 24.9 Mbits/sec 29 sender
[ 5] 0.00-10.00 sec 26.7 MBytes 22.4 Mbits/sec receiver
iperf Done
J'ai répété quelques fois ces tests et obtiens grosso modo les mêmes résultats, avec un débit IPv6 qui semble fluctuer un peu (le débit théorique de ma ligne est de 1Gbit/s en download et 800Mbit/s en upload).
Donc de mon point de vue, sans marquage particulier des paquets, j'obtiens:
- 150-200Mbit/s en v6, qui fluctue pas mal,
- ~22Mbit/s en v4, sans aucune fluctuations.
Il n'y a pas de marquage CoS / DSCP spécifique sur ces paquets, et les options --tos et --dscp d'iperf3 semblent ne rien faire (i.e. ne pas générer de marquage) sur ma machine de test. Donc je suppose qu'ils sont tous marqués cs0.
Le débit fluctuant en IPv6 fait penser à une congestion sur une interco, et par défaut mes tests utilisent cubic. J'ai donc refait des tests avec bbr, qui a tendance à s'accaparer la bande passante des flux cubic:
$ iperf3 -c 2a03:7220:8081:9f00::1 -t 120 --congestion bbr
Connecting to host 2a03:7220:8081:9f00::1, port 5201
[ 5] local 2a01:cb08:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 52478 connected to 2a03:7220:8081:9f00::1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 24.4 MBytes 204 Mbits/sec 0 1.11 MBytes
[ 5] 1.00-2.00 sec 26.2 MBytes 220 Mbits/sec 0 1.20 MBytes
[ 5] 2.00-3.00 sec 23.8 MBytes 199 Mbits/sec 0 1.08 MBytes
[ 5] 3.00-4.00 sec 26.2 MBytes 220 Mbits/sec 0 1.26 MBytes
[ 5] 4.00-5.00 sec 22.5 MBytes 189 Mbits/sec 0 1.24 MBytes
[ 5] 5.00-6.00 sec 25.0 MBytes 210 Mbits/sec 10 1.14 MBytes
[ 5] 6.00-7.00 sec 25.0 MBytes 210 Mbits/sec 0 1.19 MBytes
[ 5] 7.00-8.00 sec 25.0 MBytes 210 Mbits/sec 0 1.18 MBytes
[ 5] 8.00-9.00 sec 25.0 MBytes 210 Mbits/sec 0 1.24 MBytes
[ 5] 9.00-10.00 sec 26.2 MBytes 220 Mbits/sec 0 1.23 MBytes
^C[ 5] 10.00-10.43 sec 5.00 MBytes 97.8 Mbits/sec 0 1.17 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.43 sec 254 MBytes 205 Mbits/sec 10 sender
[ 5] 0.00-10.43 sec 0.00 Bytes 0.00 bits/sec receiver
iperf3: interrupt - the client has terminated
$ iperf3 -c 2a03:7220:8081:9f00::1 -t 120 --reverse --congestion bbr
Connecting to host 2a03:7220:8081:9f00::1, port 5201
Reverse mode, remote host 2a03:7220:8081:9f00::1 is sending
[ 5] local 2a01:cb08:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 41116 connected to 2a03:7220:8081:9f00::1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 25.5 MBytes 213 Mbits/sec
[ 5] 1.00-2.00 sec 30.4 MBytes 256 Mbits/sec
[ 5] 2.00-3.00 sec 28.2 MBytes 237 Mbits/sec
[ 5] 3.00-4.00 sec 30.1 MBytes 253 Mbits/sec
[ 5] 4.00-5.00 sec 27.6 MBytes 232 Mbits/sec
[ 5] 5.00-6.00 sec 24.1 MBytes 203 Mbits/sec
[ 5] 6.00-7.00 sec 29.6 MBytes 248 Mbits/sec
[ 5] 7.00-8.00 sec 28.0 MBytes 235 Mbits/sec
[ 5] 8.00-9.00 sec 30.6 MBytes 257 Mbits/sec
^C[ 5] 9.00-9.54 sec 16.3 MBytes 254 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-9.54 sec 0.00 Bytes 0.00 bits/sec sender
[ 5] 0.00-9.54 sec 271 MBytes 238 Mbits/sec receiver
iperf3: interrupt - the client has terminated
Un chouilla mieux, mais vraiment à peine. Donc probablement de la congestion entre Orange et Tetraneutral sur le chemin emprunté depuis chez moi.
Pas de changement en v4 en utilisant bbr, toujours bloqué à 22.6Mbit/s.
Si tu vois une limite à 5Mbit/s en IPv6 et que la seule différence entre ta config et la mienne est la présence de la box, je pense que la box y est pour quelque chose.
Traceroute depuis chez moi:
$ mtr -bzwe6 pouzenc.fr
Start: 2025-07-28T13:18:42+0000
HOST: probe1 Loss% Snt Last Avg Best Wrst StDev
1. AS3215 naxos (2a01:cb08:xxxx:xxxx::1) 0.0% 10 0.6 0.7 0.5 0.8 0.1
2. AS3215 2a01cb08a00402150193025300760242.ipv6.abo.wanadoo.fr (2a01:cb08:a004:215:193:253:76:242) 0.0% 10 1.8 1.8 1.1 2.5 0.4
3. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4. AS??? 2a01:cfc4:0:400::3 40.0% 10 8.9 8.6 8.2 8.9 0.3
5. AS197422 mail.pouzenc.fr (2a03:7220:8081:9f00::1) 0.0% 10 18.2 18.2 17.6 19.0 0.4e]
17-18ms de ping vers ton serveur, ce que je trouve un peu élevé et qui pourrait, là aussi, être synonyme de congestion.
Je reprends mes tests iperf, avec 4 streams en parallèle:
$ iperf3 -c 2a03:7220:8081:9f00::1 -t 120 --parallel 4 --congestion bbr
Connecting to host 2a03:7220:8081:9f00::1, port 5201
[ 5] local 2a01:cb08:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 40142 connected to 2a03:7220:8081:9f00::1 port 5201
[ 7] local 2a01:cb08:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 40146 connected to 2a03:7220:8081:9f00::1 port 5201
[ 9] local 2a01:cb08:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 40158 connected to 2a03:7220:8081:9f00::1 port 5201
[ 11] local 2a01:cb08:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 40164 connected to 2a03:7220:8081:9f00::1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 8.88 MBytes 74.4 Mbits/sec 7 382 KBytes
[ 7] 0.00-1.00 sec 9.38 MBytes 78.6 Mbits/sec 9 379 KBytes
[ 9] 0.00-1.00 sec 18.0 MBytes 151 Mbits/sec 68 918 KBytes
[ 11] 0.00-1.00 sec 7.62 MBytes 63.9 Mbits/sec 3 371 KBytes
[SUM] 0.00-1.00 sec 43.9 MBytes 368 Mbits/sec 87
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 1.00-2.00 sec 6.25 MBytes 52.4 Mbits/sec 38 365 KBytes
[ 7] 1.00-2.00 sec 7.50 MBytes 62.9 Mbits/sec 37 443 KBytes
[ 9] 1.00-2.00 sec 21.2 MBytes 178 Mbits/sec 270 1.21 MBytes
[ 11] 1.00-2.00 sec 7.50 MBytes 62.9 Mbits/sec 40 471 KBytes
[SUM] 1.00-2.00 sec 42.5 MBytes 357 Mbits/sec 385
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 2.00-3.00 sec 6.25 MBytes 52.4 Mbits/sec 9 321 KBytes
[ 7] 2.00-3.00 sec 7.50 MBytes 62.9 Mbits/sec 13 399 KBytes
[ 9] 2.00-3.00 sec 23.8 MBytes 199 Mbits/sec 24 1.05 MBytes
[ 11] 2.00-3.00 sec 7.50 MBytes 62.9 Mbits/sec 7 474 KBytes
[SUM] 2.00-3.00 sec 45.0 MBytes 377 Mbits/sec 53
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 3.00-4.00 sec 6.25 MBytes 52.4 Mbits/sec 35 271 KBytes
[ 7] 3.00-4.00 sec 7.50 MBytes 62.9 Mbits/sec 35 424 KBytes
[ 9] 3.00-4.00 sec 21.2 MBytes 178 Mbits/sec 34 1.25 MBytes
[ 11] 3.00-4.00 sec 7.50 MBytes 62.9 Mbits/sec 34 407 KBytes
[SUM] 3.00-4.00 sec 42.5 MBytes 357 Mbits/sec 138
^C- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 4.00-4.96 sec 3.75 MBytes 32.7 Mbits/sec 7 220 KBytes
[ 7] 4.00-4.96 sec 8.75 MBytes 76.4 Mbits/sec 36 544 KBytes
[ 9] 4.00-4.96 sec 22.5 MBytes 196 Mbits/sec 161 1.31 MBytes
[ 11] 4.00-4.96 sec 6.25 MBytes 54.5 Mbits/sec 19 388 KBytes
[SUM] 4.00-4.96 sec 41.2 MBytes 360 Mbits/sec 223
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-4.96 sec 31.4 MBytes 53.0 Mbits/sec 96 sender
[ 5] 0.00-4.96 sec 0.00 Bytes 0.00 bits/sec receiver
[ 7] 0.00-4.96 sec 40.6 MBytes 68.7 Mbits/sec 130 sender
[ 7] 0.00-4.96 sec 0.00 Bytes 0.00 bits/sec receiver
[ 9] 0.00-4.96 sec 107 MBytes 180 Mbits/sec 557 sender
[ 9] 0.00-4.96 sec 0.00 Bytes 0.00 bits/sec receiver
[ 11] 0.00-4.96 sec 36.4 MBytes 61.5 Mbits/sec 103 sender
[ 11] 0.00-4.96 sec 0.00 Bytes 0.00 bits/sec receiver
[SUM] 0.00-4.96 sec 215 MBytes 364 Mbits/sec 886 sender
[SUM] 0.00-4.96 sec 0.00 Bytes 0.00 bits/sec receiver
iperf3: interrupt - the client has terminated
$ iperf3 -c 2a03:7220:8081:9f00::1 -t 120 --parallel 4 --congestion bbr --reverse
Connecting to host 2a03:7220:8081:9f00::1, port 5201
Reverse mode, remote host 2a03:7220:8081:9f00::1 is sending
[ 5] local 2a01:cb08:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 36764 connected to 2a03:7220:8081:9f00::1 port 5201
[ 7] local 2a01:cb08:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 36768 connected to 2a03:7220:8081:9f00::1 port 5201
[ 9] local 2a01:cb08:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 36782 connected to 2a03:7220:8081:9f00::1 port 5201
[ 11] local 2a01:cb08:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 36790 connected to 2a03:7220:8081:9f00::1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 8.54 MBytes 71.7 Mbits/sec
[ 7] 0.00-1.00 sec 13.9 MBytes 117 Mbits/sec
[ 9] 0.00-1.00 sec 9.55 MBytes 80.1 Mbits/sec
[ 11] 0.00-1.00 sec 11.7 MBytes 98.5 Mbits/sec
[SUM] 0.00-1.00 sec 43.8 MBytes 367 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 1.00-2.00 sec 9.11 MBytes 76.4 Mbits/sec
[ 7] 1.00-2.00 sec 16.1 MBytes 135 Mbits/sec
[ 9] 1.00-2.00 sec 8.34 MBytes 70.0 Mbits/sec
[ 11] 1.00-2.00 sec 12.5 MBytes 105 Mbits/sec
[SUM] 1.00-2.00 sec 46.0 MBytes 386 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 2.00-3.00 sec 9.00 MBytes 75.5 Mbits/sec
[ 7] 2.00-3.00 sec 16.3 MBytes 137 Mbits/sec
[ 9] 2.00-3.00 sec 8.57 MBytes 71.9 Mbits/sec
[ 11] 2.00-3.00 sec 12.6 MBytes 106 Mbits/sec
[SUM] 2.00-3.00 sec 46.5 MBytes 390 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 3.00-4.00 sec 8.90 MBytes 74.6 Mbits/sec
[ 7] 3.00-4.00 sec 15.6 MBytes 130 Mbits/sec
[ 9] 3.00-4.00 sec 7.37 MBytes 61.9 Mbits/sec
[ 11] 3.00-4.00 sec 12.1 MBytes 101 Mbits/sec
[SUM] 3.00-4.00 sec 43.9 MBytes 368 Mbits/sec
^C- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 4.00-4.64 sec 6.37 MBytes 83.4 Mbits/sec
[ 7] 4.00-4.64 sec 10.2 MBytes 133 Mbits/sec
[ 9] 4.00-4.64 sec 4.73 MBytes 61.9 Mbits/sec
[ 11] 4.00-4.64 sec 7.97 MBytes 104 Mbits/sec
[SUM] 4.00-4.64 sec 29.3 MBytes 383 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-4.64 sec 0.00 Bytes 0.00 bits/sec sender
[ 5] 0.00-4.64 sec 41.9 MBytes 75.8 Mbits/sec receiver
[ 7] 0.00-4.64 sec 0.00 Bytes 0.00 bits/sec sender
[ 7] 0.00-4.64 sec 72.1 MBytes 130 Mbits/sec receiver
[ 9] 0.00-4.64 sec 0.00 Bytes 0.00 bits/sec sender
[ 9] 0.00-4.64 sec 38.6 MBytes 69.7 Mbits/sec receiver
[ 11] 0.00-4.64 sec 0.00 Bytes 0.00 bits/sec sender
[ 11] 0.00-4.64 sec 56.9 MBytes 103 Mbits/sec receiver
[SUM] 0.00-4.64 sec 0.00 Bytes 0.00 bits/sec sender
[SUM] 0.00-4.64 sec 209 MBytes 379 Mbits/sec receiver
iperf3: interrupt - the client has terminated
Donc ~380Mbit/s dans les deux sens, plus ou moins, avec plusieurs connexions bbr. Donc encore plus de chances de "gagner" par rapport aux autres flux et de leur prendre leur bande passante.
Mon routeur ne fait rien du marquage CoS/DSCP et l'ONT est celui fourni par Orange/Sosh,
Au doigt mouillé, je dirai que:
- quelque chose fait du policing en IPv4, mais je ne sais pas si c'est le réseau d'Orange ou un autre,
- le chemin IPv6 entre Orange et Tetraneutral est congestionné mais ne semble pas, à priori, subir de QoS spécifique *sans la box*.
Je vais essayer de creuser pourquoi iperf ignore mes options --dscp/--tos car j'aurai bien aimé pouvoir comparer avec cs1, qui est ce que scp utilise par défaut.
As-tu moyen de faire des tests sans la box, avec un routeur tiers ou l'ONT directement connecté à ta machine de test? Il faudra configurer un VLAN et des options DHCP spécifiques, ce n'est pas plug and play.
-
Personnellement, je suis bridé à exactement 5 Mb/s (c'est extrêmement stable) et ce débit est le débit pour l'ensemble des connexions SSH que je monte.
Quand je fais un transfert sur plusieurs PC :
- PC Vivien <= Box 5G Orange <= Livebox FTTH <= PC 1 (port N°1)
- PC Vivien <= Box 5G Orange <= Livebox FTTH <= PC 2 (port N°2)
Le débit de 5 Mb/s est mutualisé entre les deux PC (je me demandais si j'arriverais à un débit cumulé de 10 Mb/s, mais non).
Là, c'est 2 PC derrière la même Livebox FTTH, je testerais depuis 2 livebox différentes.
-
Le débit de 5 Mb/s est mutualisé entre les deux PC (je me demandais si j'arriverais à un débit cumulé de 10 Mb/s, mais non).
Le fait que tous les flux appartenant à la même classe de service soient bridés à 5Mbit/s met en évidence l'existence d'un policing par classe.
Là, c'est 2 PC derrière la même Livebox FTTH, je testerais depuis 2 livebox différentes.
C'est un bon test : cela nous permettra de savoir où la QoS est appliquée (réseau fixe ou mobile).
Je pressens qu'elle est appliquée par le réseau mobile, mais on voit que dans certains cas (c.f. réseau fixe vers tetraneutral) qu'il peut aussi y avoir du policing dans le réseau fixe.