La Fibre

Fournisseurs d'accès à Internet fixe en France métropolitaine => Orange / Sosh => Orange fibre Débit fibre => Discussion démarrée par: vivien le 12 août 2024 à 22:12:16

Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté 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
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 13 août 2024 à 09:25:59
Citation de: 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 ?

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.

Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 13 août 2024 à 09:45:30
Citation de: levieuxatorange le 13 août 2024 à 09:25:59
- 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.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: simon le 13 août 2024 à 10:15:25
Citation de: vivien le 13 août 2024 à 09:45:30
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.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 14 août 2024 à 08:58:33
Citation de: vivien le 13 août 2024 à 09:45:30
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

Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 14 août 2024 à 13:56:57
Citation de: simon le 13 août 2024 à 10:15:25
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.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 16 septembre 2024 à 22:51:33
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
Code: [Sélectionner]
# 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
Code: [Sélectionner]
# 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)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 16 septembre 2024 à 22:57:41
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)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 16 septembre 2024 à 22:59:18
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)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 16 septembre 2024 à 23:00:04
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)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 16 septembre 2024 à 23:01:19
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)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 16 septembre 2024 à 23:05:51
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.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: kgersen le 16 septembre 2024 à 23:36:30
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 ?
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 17 septembre 2024 à 09:44:36
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)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 17 septembre 2024 à 12:26:35
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 ?)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 17 septembre 2024 à 13:44:28
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
Code: [Sélectionner]
# 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".
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: simon le 17 septembre 2024 à 15:31:12
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.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: baptiste_ le 21 février 2025 à 20:18:05
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.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: simon le 21 février 2025 à 21:24:28
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?
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 21 février 2025 à 22:02:45
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 :
Citation de: vivien le 17 septembre 2024 à 12:26:35
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).
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: baptiste_ le 22 février 2025 à 11:33:13
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...
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: baptiste_ le 22 février 2025 à 11:39:53
Citation de: vivien le 21 février 2025 à 22:02:45
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)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 22 février 2025 à 12:19:03
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 :
Citation de: vivien le 16 septembre 2024 à 22:51:33
2/ Mettre sur le client OpenSSH le fichier de configuration suivant :
/etc/ssh/ssh_config.d/ssh_best_effort.conf
Code: [Sélectionner]
# 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)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: baptiste_ le 22 février 2025 à 12:37:47
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é
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: simon le 24 février 2025 à 09:38:32
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.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: renaud07 le 25 février 2025 à 02:53:51
+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.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: simon le 25 février 2025 à 09:32:12
Citation de: renaud07 le 25 février 2025 à 02:53:51
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.
Titre: Fibre Sosh, certains flux IPv6 shapés à 5Mbit/s ?
Posté par: lpouzenc le 28 juillet 2025 à 13:46:41
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
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 28 juillet 2025 à 14:36:03
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 :

Citation de: vivien le 06 novembre 2021 à 14:06:55
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
Code: [Sélectionner]
# 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
Code: [Sélectionner]
# 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
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: simon le 28 juillet 2025 à 15:33:02
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):

Code: [Sélectionner]
$ 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:

Code: [Sélectionner]
$ 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:
Code: [Sélectionner]
$ 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:
Code: [Sélectionner]
$ 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.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 28 juillet 2025 à 16:07:29
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.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: simon le 28 juillet 2025 à 17:04:06
Citation de: vivien le 28 juillet 2025 à 16:07:29
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.

Citation de: vivien le 28 juillet 2025 à 16:07:29
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.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: Seb65 le 29 juillet 2025 à 09:41:56
Pas de bridage depuis la connexion FTTH Sosh, Livebox 5:

Code: [Sélectionner]
$ iperf3 -c 2a03:7220:8081:9f00::1
Connecting to host 2a03:7220:8081:9f00::1, port 5201
[  5] local 2a01:cb19:8e6a:1100:384e:71ff:fe10:fc87 port 48908 connected to 2a03:7220:8081:9f00::1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  17.0 MBytes   143 Mbits/sec    0   1.04 MBytes       
[  5]   1.00-2.00   sec  55.0 MBytes   461 Mbits/sec    0   3.13 MBytes       
[  5]   2.00-3.00   sec  70.0 MBytes   587 Mbits/sec  184   1.54 MBytes       
[  5]   3.00-4.00   sec  43.8 MBytes   367 Mbits/sec    0   1.65 MBytes       
[  5]   4.00-5.00   sec  45.0 MBytes   377 Mbits/sec    1   1.21 MBytes       
[  5]   5.00-6.00   sec  33.8 MBytes   283 Mbits/sec    0   1.30 MBytes       
[  5]   6.00-7.00   sec  35.0 MBytes   294 Mbits/sec    0   1.36 MBytes       
[  5]   7.00-8.00   sec  36.2 MBytes   304 Mbits/sec    0   1.40 MBytes       
[  5]   8.00-9.00   sec  38.8 MBytes   325 Mbits/sec    0   1.43 MBytes       
[  5]   9.00-10.00  sec  40.0 MBytes   336 Mbits/sec    0   1.45 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   414 MBytes   348 Mbits/sec  185             sender
[  5]   0.00-10.04  sec   412 MBytes   344 Mbits/sec                  receiver

iperf Done.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: simon le 29 juillet 2025 à 10:02:39
Citation de: Seb65 le 29 juillet 2025 à 09:41:56
Pas de bridage depuis la connexion FTTH Sosh, Livebox 5:

Donc avec ou sans Livebox, pas de bridage en IPv6 vers tetraneutral mais un débit assez fluctuant.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: lpouzenc le 29 juillet 2025 à 11:34:02
Citation de: simon le 28 juillet 2025 à 15:33:02
[...]
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.

Merci pour ta réponse extensive !

Je vais essayer de checker le champ DSCP, et voir. Ce qui m'étonne c'est que le iperf3 se fait shaper dans mon cas, pas juste du tunnel ssh qui aurait été en interactif au lieu de bulk par erreur par exemple.

Ma livebox 5 a un ONT interne, et je ne suis pas pour l'instant très chaud d'acheter un ONT, bien qu'on m'a déjà suggéré un modèle précis et des détails pour que ça puisse marcher... Surtout que je peux juste upload en IPv4 pour les maigres cas pénibles. En terme de neutralité du net et de on a envie de savoir, c'est pas une réponse très satisfaisante que je fais là, j'en ai conscience.

Ludovic
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: lpouzenc le 29 juillet 2025 à 12:19:53
Citation de: vivien le 28 juillet 2025 à 14:36:03
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.

Come j'avais fais des iperf sans options et du borg backup over ssh, je me suis dit que je pouvais faire un essai avec les ssh_config et sshd_config que tu as mentionné. C'est chose faite et ça n'améliore pas la situation :


root@nuc1:~# pv /mnt/grosfichier.mts | ssh root@pouzenc.fr dd of=/dev/null
^C84MiO 0:00:14 [ 604KiO/s] [>                                                                                                       ]  0% ETA 5:32:37
root@nuc1:~# pv /mnt/grosfichier.mts | ssh -4 root@pouzenc.fr dd of=/dev/null
^C51MiO 0:00:04 [83,3MiO/s] [>                                                                                                       ]  1% ETA 0:03:39


Je vais wireshark un coup mais je pense que j'envoi du cs0 presque dans tous les cas.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: lpouzenc le 29 juillet 2025 à 12:58:07
Pour mon cas Abonnement Sosh, fibre Livebox 5 vers tetaneutral.net en IPv6 qui est shapé à 5Mbit/s (IPv4, non, autres destinations essayées : non), en capturant sur les machines source et destination, je vois que le champ DSCP est modifié en chemin.

J'ai lancé un :
root@nuc1:~# pv /mnt/grosfichier.mts | ssh root@pouzenc.fr dd of=/dev/null

En capturant ce même flux à deux endroits : sur nuc1 et sur la VM qui réponds au bout du DNS pouzenc.fr :

Vu de la capture sur nuc1, paquets nuc1->pouzenc.fr :
.... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)

Vu de la capture sur pouzenc.fr paquets nuc1->pouzenc.fr :
.... 0001 0100 .... .... .... .... .... = Traffic Class: 0x14 (DSCP: Unknown, ECN: Not-ECT)


Vu de la capture sur nuc1, paquets pouzenc.fr->nuc1 :
.... 1010 0000 .... .... .... .... .... = Traffic Class: 0xa0 (DSCP: CS5, ECN: Not-ECT)

Vu de la capture sur pouzenc.fr paquets pouzenc.fr->nuc1  :
.... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)

Ludovic
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 31 juillet 2025 à 09:58:19
baptiste_, je reviens sur ton cas :

Citation de: baptiste_ le 21 février 2025 à 20:18:05
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.
As-tu pu tester un tunnel Wireguard avec une Livebox des deux cotés ?

Le routeur Mikrotik serait-il un élément important pour avoir cette limitation à 5 Mb/s ?

Il me semble comprendre que ton tunnel est monté en IPv4, le problème est-il présent en IPv6 ?

(pour lpouzenc, la limitation n'est présente qu'en IPv6, IPv4 non limité à 5 Mb/s et dans mon cas je n'ai testé que IPv4, ce qui me bloque pour IPv6, c'est le firewall de la Livebox, je ne sais pas si il y a une solution pour ne pas reconfigurer le firewall IPv6 de la Livebox à chaque changement de préfixe IPv6, sachant je n'ai pas un accés simple à la Livebox)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: daleksek le 31 juillet 2025 à 11:41:55
J'utilise IPQoS cs0 depuis quelques temps sinon c'est bridé,
Je suis en IPV4 only,

Transferts de fichier via SSH, FTTH Bouygues récupère des fichiers sur FTTH Orange :
Si le paramètre IPQoS cs0 n'est pas présent, je plafonne à environ 5 mbits d'upload
Si j'utilise tailscale qui fonctionne avec wireguard, je n'ai plus la limite, la seule limite c'est le CPU de la machine, je montes à 70-80Mo/s d'upload
Si le paramètre IPQoS cs0 est présent, la connexion en direct n'est plus bridée, j'atteins bien les 1 Gbits d'upload,
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 31 juillet 2025 à 12:49:56
daleksek je récapitule :
- Serveur SSH : derrière une Livebox FTTH avec NAT ouvert vers le port en question
- Client SSH : derrière une box Bouygues FTTH

Bouygues est censé réinitialiser le champ DSP à plusieurs reprises (au niveau de la box, c'est remis à cs0, mais pour ceux qui ont remplacé la box par leur propre équipement, Bouygues remet un peu plus loin à cs0 le flux internet pour prendre en compte ce cas). Je suis donc étonné.

Quand tu parles d'upload, c'est dans quel sens ? Bouygues ⇒ Orange ?

L'IPQoS cs0, tu le mets coté PC Bouygues ou coté PC Orange ?

C'est un fichier de configuration .conf de ce type ?
Code: [Sélectionner]
IPQoS cs0 cs0

De mon coté, c'est Orange <=> Orange, j'ai juste besoin de mettre IPQoS cs0 cs0 sur le PC client, celui reçois les flux, pour ne plus avoir de limitation. C'est trés étrange, car on dirait que c'est le fait que les acquittements soient priorisés qui fait que le trafic dans l'autre sens est bridé.
Le problème est présent que le PC client soit connecté derrière ma box 5G ou sur mon mobile SOSH en partage de connexion.
Le serveur SSH est lui derrière une Livebox FTTH (j'ai des cas avec Livebox 3 et Livebox 4, je suis bridé dans les deux cas à 5 Mb/s si je ne place pas IPQoS cs0 cs0 sur le PC derrière le réseau mobile).
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: daleksek le 31 juillet 2025 à 14:41:12
J'ai toujours les box des FAI, une LB6 et Bbox Wifi 6 (le premier modèle), le port est bien ouvert.

l'upload est dans le sens Orange -> Bouygues (je n'ai jamais essayé dans l'autre sens)

J'insère le paramètre "IPQoS cs0" dans le fichier du serveur côté Orange : /etc/ssh/sshd_config

Avant je mettais "IPQoS 0x00", que j'avais trouvé sur ce forum, mais ça ne semble plus fonctionner.

Est-ce qu'il y a une différence entre "IPQoS cs0 cs0" et "IPQoS cs0"
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 31 juillet 2025 à 15:21:02
Tu as raison, ce n'est pas nécessaire de spécifier les deux, si on met la même valueur pour une session interactive et un transfert de fichier.

If one argument is specified, it is used as the packet class unconditionally.  If two values are specified, the first is automatically selected for interactive sessions and the second for non-interactive sessions.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: Max le 10 août 2025 à 13:41:43
J'ai le même problème vers deux Livebox (v6 et v7 W6E) en FTTH et un abonnement Orange 5G+ avec un tunnel WireGuard, je plafonne à 5 Mbps quand le tunnel est établi en IPv4 ou IPv6 côté Livebox et côté réseau mobile sur un iPhone en IPv6 only via 464XLAT, vers l'une ou l'autre Livebox.

En revanche avec ma SIM Free Mobile j'ai le débit maximum vers les deux Livebox et aussi entre les deux Livebox en direct que ce soit en IPv4 ou IPv6 j'ai bien le débit maximum également.

Pour résumer :
Livebox 6 <-> Orange Mobile = 5 Mbps
Livebox 7 W6E <-> Orange Mobile = 5 Mbps
Livebox 6 <-> Free Mobile = débit max
Livebox 7 W6E <-> Free Mobile = débit max
Livebox 6 <-> Livebox 7 = débit max (IPv4 et IPv6)

Du coup pour moi dans mon cas ça viendrait plutôt du réseau mobile Orange car j'ai bien le débit max entre les deux Livebox et Free Mobile...

Si quelqu'un d'Orange nous lit...
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 12 août 2025 à 09:08:59
Hello

Bon, sur le fonctionnement du réseau Orange et du DSCP petites précisions :
- grâce à l'ARCEP (coucou @vivien) qui en est le garant et à une volonté interne, seule le trafic CS0 est réellement NET NEUTRAL
- tout ce qui n'est pas CS0 est fortement contraint : par choix interne, par imposition des mains de l'ARCEP (re coucou @vivien), par (il ne faut pas le négliger) bug d'un combo de conf pas simple à trouver.

Là, le flux est tagué autre que CS0 à un moment.
Il y a des mécanismes dans le réseau qui à partir du moment où un paquet dans un flux à été tagué autre que CS0, tout le flux peut être considéré comme autre que CS0.
Et donc se prendre la limitation lié à ce DSCP sur ce flux ...
Et les endroits où ces limitations s'appliquent est en constante évolution (et je dirais renforcement).

Donc effectivement, faire BIEN attention à ce que vos flux en provenance et en direction d'internet soient BIEN CS0 et uniquement cela.
Tout le flux, tout les paquets d'un même flux.

A l'interco avec tout autres réseau c'est relativement simple tout est retagué CS0, mais en interne ORANGE France y'a des subtilités

Je vais poser la question quand même à mon gourou réseau coté mobile, mais je pense que j'ai là la bonne réponse.

LeVieux

Edit : remplacer ARCEP par ARCOM, je suis pas à la page ...
Titre: Fibre Sosh, certains flux IPv6 shapés à 5Mbit/s ?
Posté par: lpouzenc le 12 août 2025 à 15:09:27
Merci LeVieuxAtOrange de ta dernière réponse.

Mon cas de figure défie l'explication donnée. En tout cas laisse penser qu'il manque une brique dans l'affaire. cf mon post précédent.


J'ai ce jour, après 3 contacts avec le support, fait tester ma LiveBox 5 sur une borne en boutique, test passed (d'ailleurs ils branchent tous les ports ethernet et téléphone pour le test mais jamais le port fibre, c'est ... une façon intéressante de voir le sujet des diagnostics des box fibre :D). La dame en boutique m'a dit spontanément, on va la changer quand même. Elle m'a donné (et enregistré sur le réseau) une LiveBox 6 à la place d'une 5. J'ai testé en rentrant ce matin : 5mbit/s ou 5mbit/s sur un iperf3 vers tetaneutral en IPv6 et 400 ou 500 Mbit/s vers la même destination Tetaneutral en IPv4, en wifi et filaire respectivement. Tout comme les traces déjà collée dans mon précédent post avec la Livebox 5.

Je suis intéressé par avoir des flux net neutral, et je vois bien que les paquets partant de chez moi partent en CS0 et arrivent avec un DSCP exotique à l'autre bout, et les réponses partent en CS0 et arrivent chez moi avec un DSCP non CS0 également. A qui dire qu'il y a un équipement intermédiaire qui m'enquiquine ?

Je n'ai jamais tenté de modifications sur ma ligne, j'ai toujours utilisé le matériel d'origine, que je viens de changer, etc. J'ai depuis 1 an un flux la nuit qui fait un backup de chez moi vers Tetaneutral et qui parfois a consommé du débit pendant un certain temps (quelques Gio transférés par nuit dans certaines périodes, quelques dizaine de Mio sinon) mais c'est guerre tout ce que je fais d'exotique.
Aussi, depuis 1 mois j'ai bcp de congestions vers le CDN de Twitch. C'est un autre flux où il y a souvent du trafic ici. Je ne suis pas aux deux bouts pour savoir l'état des champs DSCP et ça peut être juste un probème qui n'a rien à voir et que je vois régulièrement juste parce que je l'utilise. Ou alors un équipement change des DSCP selon le profil d'utilisation, dans mon cas sur un abo fibre...

Ludovic

Citation de: lpouzenc le 28 juillet 2025 à 13:46:41
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.
Titre: Fibre Sosh, certains flux IPv6 shapés à 5Mbit/s ?
Posté par: Aize147 le 12 août 2025 à 15:35:36
Citation de: lpouzenc le 12 août 2025 à 15:09:27
Aussi, depuis 1 mois j'ai bcp de congestions vers le CDN de Twitch.

À ça malheureusement c'est OTI 5511 qui a arrêté son PNI avec Twitch.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: lpouzenc le 12 août 2025 à 16:48:17
Merci pour vos réponses.

Je viens de refaire (3 fois car pas facile de faire propre ! ) des captures aux deux extrémités dans mon cas de bridage fibre upload 5mbit/s, avec un .txt consignant les séquences de commandes utilisées. J'ai essayé du https, du iperf, du rsync over ssh sur les ports par défaut.

Pour une même paire de paquets, capturé aux deux bouts :
En IPv4 : Je vois bien des CS0 au départ de chez moi et des CS0 à l'arrivée. Idem dans le sens retour.
En IPv6 : Je vois bien des CS0 au départ de chez moi et de mon serveur chez tetaneutral...
Et à l'arrivée, dans le sens chez moi -> Tetaneutral) : des 0x14 (unknown)
dans le sens Tetaneutral -> chez moi : 0xa0 (CS5).

J'ai pu voir, pour un flux donné (follow TCP) que 100% des paquets du flux avant les TCP RST (qui sont en CS5) ont bien un champ DSCP à CS0, et tous les paquets à la destination sont altérés quand même, dès le premier d'ailleurs.

Les captures et les commandes utilisées sont là : https://www.pouzenc.fr/misc/sosh/

Ludovic
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 13 août 2025 à 09:35:11
Bonjour

Tu as effectivement un comportement très très étrange sur les CoS ...
Ce qui part de ta machine est plutôt bon.

Ce qui arrive chez Tetaneutral est plutôt exotique sur l'IPv6. Là cela pourrait aussi être une politique de remarquage par Téléneutral.
Avec des réponses en CS 5
Qui vont là effectivement imposer une limitation.

Ce que je n'explique pas c'est comment cela se fait que ce CS5 revienne jusqu'à dans nos infras.

Là c'est une question RBCI et interco en IPv6, j'ai mon experte qui est rentrée, je vais poser la question.

Mais en l'état, c'est "normal" que cela soit limité.

Contournement possible : en entré/sortie  de ta machine pouzenc, forcer le CS0. Si tu sais faire cela et que cela fait sauter la limitation, on a une vraie piste.

Si un gourou Linux peut trouver le commandes tc à mettre, cela serait une aide.

LeVieux

Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: Max le 13 août 2025 à 12:42:00
Merci LeVieux pour ta réponse :)

Je ne pense pas que le problème soit du côté Tetaneutral. Comme expliqué plus haut, j'ai exactement la même limitation en restant sur RBCI entre Orange Mobile (IPv6 via 464XLAT) et Orange FTTH, et je ne suis pas le seul, Vivien a expliqué avoir le même bridage entre une 5G Box Orange et un abonnement FTTH Orange...
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 13 août 2025 à 13:14:27
Pour mon cas, les paquets sortent avec le DSCP par défaut de OpenSSH qui n'est pas zéro, mais le tag est modifié par le réseau (je n'ai pas le même tag au départ et à l'arrivée). Maintenant, cela ne me semble logique qu'entre certains parie du réseau le DSCP soit modifié. Je suis plus étonné par le fait qu'un trafic client ne soit pas re-tagué pour éviter qu'un client puisse priorises ses propres flux (que cela soit volontairement ou invonlontairement).

Tu as bien regardé le tag des acquittements TCP ? Dans mon cas, c'est vraiment sur le tag du paquet "SYN" (connexion initiée depuis le réseau mobile vers une ligne FTTH) puis des acquittements TCP qui fait que j'ai ou pas la limitation dans l'autre sens (FTTH => Mobile). C'est assez étrange que le tag des acquittements aillent entraîner une limite du flux dans l'autre sens (avec les données) à 5 Mbit/s.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: lpouzenc le 13 août 2025 à 13:28:16
Merci pour les réponses !

@Vivien : tag et shaping selon le tag DSCP / CoS du sens retour : probablemetn que ça m'affecte, mais ce n'est pas moi qui controle le champ DSCP dans l'affaire. J'ai bien pu voir un gros minet que tous les paquets partent en CS0 des deux bouts, questions, réponses, SYN, tout sauf les RST finaux.

@LeVieuxAtOrange : Pour Tetaneutral et l'hypothèse où ils tagguent en CS5 : le monsieur BGP de cet FAI associatif, et ancien président est un ami avec qui on a (publiquement, sur leur Matrix) commencé à tracer ce problème de 5Mbit/s avant que je poste ici initialement.

Ils savent qu'ils n'ont aucune config qui va dans le sens de l'altération de paquets qu'ils routent (ADN de l'asso = Neutralité du Net). On a quand même vérifié tout ce qui nous est passé par la tête, on a tenté à destination d'un autre équipement sur leur réseau pour confirmer que la VM que j'ai chez eux ou l'infra de virtu n'est pas en cause. Il a vu les plafonnements à 5Mbit/s en traçant sur le routeur de bordure. Il a même été jusqu'à me donner rendez-vous tard le soir pour altérer temporairement les annonces BGP pour qu'on tente via plusieurs chemins : le nominal, via EuroFiber, via HurricaneElectrics et un troisième chemin dont j'ai un peu oublié les détails dans l'immédiat (je peux aller chercher les archives). Le shaping à 5.0Mbit/s est toujours là. Je lui ai signalé qu'ici on avait d'autres reportings connexes et qu'il y avait un lien avec le DSCP / CoS et ça n'a pas ouvert de nouvelles pistes malheuresement, sauf les captures aux deux bouts que j'ai faites pour vérifier que ça sort en CS0 dans mon cas.

Parallèlement, j'en suis à mon 5ème appel entrant de la part du support client. L'appel du jour s'est conclu avec "je vais essayer de voir avec mon responsable, je vous rappelle samedi", la personne est démunie d'options après avoir fait changer la box et vu qu'il n'y a pas de problèmes sur le domaine optique.

Le suspens devient insoutenable :D
Ludovic
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: lpouzenc le 13 août 2025 à 13:40:26
@levieuxatorange : J'avais manqué de lire une partie de ta réponse avant mon précédent message:

Citation de: levieuxatorange le 13 août 2025 à 09:35:11
Contournement possible : en entré/sortie  de ta machine pouzenc, forcer le CS0. Si tu sais faire cela et que cela fait sauter la limitation, on a une vraie piste.
Si un gourou Linux peut trouver le commandes tc à mettre, cela serait une aide.
LeVieux

Je pense pouvoir construire la commande tc moi même (j'ai fais ça dans mes erreurs de jeunesses pour des liens radio...), mais le problème est que ... je suis déjà à l'objectif je crois : tous les paquets sortants de pouzenc.fr sont en CS0 sauf les RST en fin de flux.

Ou alors je comprends mal ce à quoi tu as pensé, dis-moi.

Je peux bien changer en CS0 en input sur pouzenc.fr mais comme je sais que c'est pas mon linux localement qui shape et que les paquets ne seront vu par aucun intermédiaire supplémentaire quand ils en sont là... je crains que ça soit vain. Tout l'art est de savoir où est l'équipement qui change "dans mon dos" les valeurs de CoS. Et ça semble pas chez TTN ni chez les opérateurs qu'il ont en peering/transit car on a essayé 3 routages possibles en suspendant des annonces BGP le temps des essais.

Ludovic
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 13 août 2025 à 14:02:08
Re

Si tu prends la partie IPv6 entrante sur pouzenc, on voit que dès le 4ème Pkts, tu es en CoS 5 :

Le filtre wire shark : tcp.stream eq 2

Code: [Sélectionner]
51 5.368489 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e 2a03:7220:8081:9f00::1 TCP 5 94 46034 → 443 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 SACK_PERM TSval=1558071745 TSecr=0 WS=128
52 5.368549 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e TCP CS0 94 443 → 46034 [SYN, ACK] Seq=0 Ack=1 Win=64260 Len=0 MSS=1440 SACK_PERM TSval=2624539501 TSecr=1558071745 WS=128
53 5.392006 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e 2a03:7220:8081:9f00::1 TCP 5 86 46034 → 443 [ACK] Seq=1 Ack=1 Win=64896 Len=0 TSval=1558071767 TSecr=2624539501
54 5.392993 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e 2a03:7220:8081:9f00::1 TLSv1.2 5 603 Client Hello[Packet size limited during capture]

Et cela sur tout cet échange

Si on regarde la partie NUC sur le même échange (elles sont super tes captures !) on voit bien que tu reçois du CS05 dès le SYN/ACK. Et là c'est mort, la régulation va se mettre en place.

Code: [Sélectionner]
53 5.368395 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e 2a03:7220:8081:9f00::1 TCP CS0 94 46034 → 443 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 SACK_PERM TSval=1558071745 TSecr=0 WS=128
54 5.390265 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e TCP CS5 94 443 → 46034 [SYN, ACK] Seq=0 Ack=1 Win=64260 Len=0 MSS=1440 SACK_PERM TSval=2624539501 TSecr=1558071745 WS=128
55 5.390390 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e 2a03:7220:8081:9f00::1 TCP CS0 86 46034 → 443 [ACK] Seq=1 Ack=1 Win=64896 Len=0 TSval=1558071767 TSecr=2624539501
56 5.390938 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e 2a03:7220:8081:9f00::1 TLSv1.2 CS0 603 Client Hello[Packet size limited during capture]


Si on prend le stream 9 des deux coté, là c'est le NUC qui positionne des le SYN la CoS à 4
Code: [Sélectionner]
77132 29.269959 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e 2a03:7220:8081:9f00::1 TCP 4 94 34110 → 22 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 SACK_PERM TSval=1558095646 TSecr=0 WS=128
77133 29.290403 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e TCP CS5 94 22 → 34110 [SYN, ACK] Seq=0 Ack=1 Win=64260 Len=0 MSS=1440 SACK_PERM TSval=2624563402 TSecr=1558095646 WS=128
77134 29.290515 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e 2a03:7220:8081:9f00::1 TCP 4 86 34110 → 22 [ACK] Seq=1 Ack=1 Win=64896 Len=0 TSval=1558095667 TSecr=2624563402
77135 29.291195 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e 2a03:7220:8081:9f00::1 SSHv2 4 119 Client: Protocol (SSH-2.0-Op)
77136 29.312950 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e TCP CS5 86 22 → 34110 [ACK] Seq=1 Ack=34 Win=64256 Len=0 TSval=2624563425 TSecr=1558095667
77137 29.321268 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e SSHv2 CS5 126 Server: Protocol (SSH-2.0-Op)
77138 29.321331 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e 2a03:7220:8081:9f00::1 TCP 4 86 34110 → 22 [ACK] Seq=34 Ack=41 Win=64896 Len=0 TSval=1558095697 TSecr=2624563433

Et pouzenc, il fait des trucs encore plus exotiques :

Code: [Sélectionner]
125880 29.269425 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e 2a03:7220:8081:9f00::1 TCP 5 94 34110 → 22 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 SACK_PERM TSval=1558095646 TSecr=0 WS=128
125881 29.269486 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e TCP CS0 94 22 → 34110 [SYN, ACK] Seq=0 Ack=1 Win=64260 Len=0 MSS=1440 SACK_PERM TSval=2624563402 TSecr=1558095646 WS=128
125882 29.291899 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e 2a03:7220:8081:9f00::1 TCP 5 86 34110 → 22 [ACK] Seq=1 Ack=1 Win=64896 Len=0 TSval=1558095667 TSecr=2624563402
125883 29.291900 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e 2a03:7220:8081:9f00::1 SSHv2 5 119 Client: Protocol (SSH-2.0-Op)
125884 29.291940 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e TCP CS0 86 22 → 34110 [ACK] Seq=1 Ack=34 Win=64256 Len=0 TSval=2624563425 TSecr=1558095667
125885 29.300307 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e SSHv2 CS0 126 Server: Protocol (SSH-2.0-Op)
125886 29.322392 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e 2a03:7220:8081:9f00::1 TCP 5 86 34110 → 22 [ACK] Seq=34 Ack=41 Win=64896 Len=0 TSval=1558095697 TSecr=2624563433
125887 29.322411 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e SSHv2 CS0 1222 Key Exchange Init[Packet size limited during capture]

Y'a une grosse bataille dans les CoS  en tout cas..

Je fais regarder à l'interco IPv6 en bordure du RBCI, mais là y'a un truc sans même parler ce cela.

LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: lpouzenc le 13 août 2025 à 14:34:12
> Je fais regarder à l'interco IPv6 en bordure du RBCI, mais là y'a un truc sans même parler ce cela.

Merci !

J'essaie de reprendre les cas que tu as regardé :
tcp.stream eq 2 :
- c'est initié depuis chez moi, avec la commande : $ wget -6qO - https://pouzenc.fr/ip.php
- l'IP en 2a01:c... c'est le nuc chez moi (Orange). L'IP en 2a03 c'est le serveur pouzenc.fr.

 Ma lecture (fausse ?) de la situation : si on regarde n'importe quel des 10 premiers paquets de ce flux, et qu'on regarde pour un même paquet donné une capture puis l'autre, il me semble qu'on constate que :
-  le nuc envoi en CS0
- pouzenc.fr reçoit en 0x14 si on prends les 8 bits incluant l'ECN (ce qui est "5" si on regarde les 6 bits de l'ECN mais pas CS5, ça peut être d'ailleurs un blague de conf sur un CLI d'un routeur type cisco sur le chemin ça !)
- pouzenc.fr réponds en CS0
- le nuc reçoit en CS5 (0xa0 en incluant les bits d'ECN)

Donc je suis d'accord avec :  on voit que dès le 4ème Pkts, tu es en CoS 5.
Et j'ajoute : en fait, oui même dès le premier paquet... et ce n'est pas "moi" (aucune de mes 2 linux d'extrémité) qui choisi cette valeur, elle est altérée sur le chemin malgré moi.

"elles sont super tes captures !" : j'ai juste passé bcp plus de temps que de raisonnable car grande vacances :D Merci.

"on voit bien que tu reçois du CS05 dès le SYN/ACK. Et là c'est mort, la régulation va se mettre en place.". Oui. Sauf que je ne choisi pas de faire ça, je subit ça. J'ai émis 100% (certes sauf les RST à la fin et j'ignore pourquoi c'est comme ça) des paquets en CS0 dans les deux sens et ils arrivent altérés dans les deux sens, et ça shape.

tcp.stream eq 9 :
- c'est initié depuis chez moi, avec la commande : $ rsync -e 'ssh -6' /dev/shm/rand100Mio.dat root@pouzenc.fr:/dev/shm/rand6.dat
- numéro du premier paquet dans la capture côté nuc : 77132

Là, effectivement, mon nuc emet avec la CoS 4 au début de la conversation, puis en CoS 2 au bout d'un moment (dès le paquet 77167, donc environ 30 paquets après le début de l'échange), inconnue du dissecteur de Wireshark. Ça je peux forcer pour que ça ne se produise pas, on devrait avoir la même chose que le stream eq 2 si je le fais (mais en port 22 et pas 443). On peut remarquer qu'un intermédiaire a forcé cette CoS 4 à une CoS 5, tout comme quand j'envoi en CS0, ça devient CoS 5.

"Et pouzenc, il fait des trucs encore plus exotiques :". Je dirai : pas tant. Pour moi, il se contente de toujours répondre en CS0 (il a l'IP en 2a03) lorsqu'il reçoit du nuc (2a01:c) des DSCP étonnants mais en fait toujours identiques à la valeur CoS5, quelque soit la valeur d'origine émise.

Edit : Cette affirmation pour moi se vérifie bien avec le filtre "(ipv6) && (ipv6.src == 2a03:7220:8081:9f00::1)" sur la capture *depuis-pouzenc.fr.pcap". Les seules exceptions sont un float de RST durant une commande iperf3, elles sont là :
Code: [Sélectionner]
No.     Time            Source                  Destination                             Proto.  DSCP    Info
2988 14.594550 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e TCP CS0 5201 → 55496 [RST, ACK] Seq=1 Ack=2626130 Win=361984 Len=0 TSval=2624548727 TSecr=1558080889
2989 14.594784 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e TCP CS0 5201 → 55488 [PSH, ACK] Seq=5 Ack=166 Win=64256 Len=1 TSval=2624548728 TSecr=1558080890
2991 14.597031 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e TCP 5 5201 → 55496 [RST] Seq=1 Win=0 Len=0
2993 14.599494 2a03:7220:8081:9f00::1 2a01:cb15:82c5:2600:20e:c6ff:fe6a:b41e TCP 5 5201 → 55496 [RST] Seq=1 Win=0 Len=0

La doc de ssh_config pour le paramètre IPQoS : Specifies the IPv4 type-of-service or DSCP class for connections. The default is af21 (Low-Latency Data) for interactive sessions and cs1 (Lower Effort) for non-interactive sessions. J'ai un peu du mal à faire les correspondances entre les valeurs acceptées dans la config et les valeurs qu'on lit uen fois décodé par Wireshark, mais tout le monde semble d'accord sur la valeur de CS0 en tout cas.

Le registre officeil des valeurs de ces champs DSCP pour IPv6 : https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml#dscp-registry-1

Merci pour le temps passé le nez dans les pcap...
Ludovic
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: lpouzenc le 18 août 2025 à 23:24:07
J'ai creusé la question des valeurs "unknown" vu de Wireshark à propos du champ DSCP des flux SSH. Dans mon dernier post, j'avais mentionné un extrait du man de ssh_config, et j'ai pris le man de debian 13.

Les distributions debian-based (dont Ubuntu) ont en production des versions d'OpenSSH avec un patch ajouté en 2019 qui revert un commit de 2018 des développeurs d'OpenSSH sur un changement de valeurs par défaut du paramètre IPQoS. D'autres distributions comme Fedora (ou toutes les autres ?) ont fait le choix en 2019 de ne pas revert comme Debian et tant pis pour les problèmes en aval : iptables -m tos avait un bug à ce sujet qui a traîné, et VMWare Player avait un bug aussi, qui a été corrigé après que les premières Fedora coincent des utilisateurs.

Dans Debian les valeurs par défaut de IPQoS sont des valeurs du temps ancien où le champ était un TOS et pas un DSCP. Dans les autres distro c'est af21 cs1.

OpenSSH a ajouté des patchs le mois passé pour rendre deprecated les valeurs de IPQoS qui sont des valeurs de TOS : https://marc.info/?l=openbsd-cvs&m=175396095604983&w=2

J'ai ouvert un bug Debian pour demander de reconsidérer le patch qu'ils traînent depuis 2019 :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111446

Un mainteneur à répondu que son plan est de supprimer le patch Debian dès qu'il intégrera une prochaine release de OpenSSH ayant la nouvelle modif susmentionnée... Donc en gros, Debian 13 va garder les valeurs par défaut désuètes, Debian 14 aura des valeurs DSCP comme les autres distro linux.


As-t'on des nouvelles côté IPv6 + DSCP + RBCI Orange ?
Je parle de : "Je fais regarder à l'interco IPv6 en bordure du RBCI, mais là y'a un truc sans même parler ce cela. LeVieux"

Ludovic
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 19 août 2025 à 08:52:53
Citation de: lpouzenc le 18 août 2025 à 23:24:07
As-t'on des nouvelles côté IPv6 + DSCP + RBCI Orange ?
Je parle de : "Je fais regarder à l'interco IPv6 en bordure du RBCI, mais là y'a un truc sans même parler ce cela. LeVieux"

Nop, pas encore c'est pas au sommet de la pile et y'a encore pas mal d'expert(e)s en congé

LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: renaud07 le 19 août 2025 à 17:04:25
Ces DSCP étranges me font penser que j'ai failli poster un message il a quelques jours car je recevais les paquets de mon VPN entre ma ligne orange et ma 4G bouygues en AF22 alors que je marquais en EF... et même après avoir retiré le marquage ça continuait.

Puis j'ai fini par m'apercevoir en faisant une capture du reste du trafic qu'en fait tout était retagué par Bouygues en AF22, probablement en entrée du réseau mobile. Par contre côté orange, le comportement est correct avec retag en CS0.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 19 août 2025 à 17:08:39
Y'a quand même un truc pas clean qui traine sur une des interco avec un remarquage à CS0 qui doit manquer.
Dans un sens comme dans l'autre d'ailleurs je dirais. Les marquages DSCP sont spécifiques à chaque réseau et une interco DSCP est toujours issue d'un accord des deux partie ...

Mais comme les interco de peering changent régulièrement, pas toujours évident de pas rater un truc.
Comme j'ai écrit auparavant, c'est comme les problème de MTU : tout sauf simple à trouver où est le point qui gène.

Dès que j'ai plus de monde de retour, je vais demander un point la dessus.

LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 19 août 2025 à 17:32:21
Pendant de nombreuses années, le trafic Bouygues standard n'était pas en DSCP 0, mais en DSCP 10. DSCP 0 était réservé au trafic dépriorisé, notamment le peer-to-peer (ports TCP exotiques et trafic UDP). Cela partait d'une bonne intention : que le trafic peer to peer sur une petite connexion ADSL ne bride pas le trafic http / https (caractérisé par le port TCP 80 et TCP 443) : en cas de saturation du lien ADSL, le trafic DSCP 0 ne pouvait pas dépasser 50%, laissant donc un minimum de 50% pour le trafic http / https en DSPC 10. Bien sûr, s'il n'y a que du trafic DSCP 0 il peut prendre tout le lien, mais chaque paquet DSP 10 sera priorisé, dans la limite de 50% du lien.

J'ai souvenir que ce tag DSCP 10 présent sur l'ensemble du trafic http / https grand public (y compris en sortie en peering, l'opérateur Adeli mon hébergeur pour lafibre.info à l'époque, ne réinitialise pas le DSCP en entrant et j'avais encore le DSCP 10 pour tout le trafic Bouygues).
Sur le LAN des clients, le DSCP 10 pouvait poser un problème avec certains points d'accès Wi-Fi.

Les serveurs DNS de Bouygues avaient un DSCP plus élevé pour éviter qu'une congestion drop les requêtes DNS.

Voici une capture de 2017 d'une connexion SSH initiée depuis le réseau mobile Bouygues vers 37.187.131.220 (OVH) sur le port 22, on voit que la réponse provenant d'internet n'est pas en DSCP 0, mais en DSCP  20 (AF22 = DSCP 20) et a donc été retagé par Bouygues en entrée de réseau.

On voit aussi qu'à cette époque le trafic SSH émis par mon PC n'est pas en DSPC 0 (trafic émis par mon PC qui sera retagé par Bouygues) :
Citation de: vivien le 22 juin 2017 à 09:41:42
Ce matin, avec mon Galaxy s7 équipé d'Android 7.0 et un abonnement Bouygues Telecom, j'ai une limitation à 5 secondes. Je ne sais pas si c'est lié au téléphone qui réalise une double NAT et que je viens d'upgrader sous Android 7.0 ou si c'est lié à une modification du NAT sur le réseau Bouygues Telecom.


Voici une capture réalisée coté client et le paramètre ClientAliveInterval 14:

La connexion se termine à la 5ᵉ seconde. Je laisse ensuite le terminal 9 secondes sans rien faire. À la 14ᵉ seconde, on voit un échange TCP qui est rejeté par le NAT, qui a donc déjà libéré les ressources : il répond RESET.

C'est la même chose pour les deux paquets émis à la 19ᵉ seconde :
(https://lafibre.info/images/wireshark/201706_ssh_cgnat_clientaliveinterval_14sec.png)

Voici la capture Wireshark complète, avec ClientAliveInterval 14:
201706_ssh_cgnat_clientaliveinterval_14sec.pcapng.gz (https://lafibre.info/images/wireshark/201706_ssh_cgnat_clientaliveinterval_14sec.pcapng.gz)

Voici la capture Wireshark complète, avec ClientAliveInterval 4:
201706_ssh_cgnat_clientaliveinterval_4sec.pcapng.gz (https://lafibre.info/images/wireshark/201706_ssh_cgnat_clientaliveinterval_4sec.pcapng.gz)
Je ne fais rien, mais la communication est forcé de rester ouverte par des échanges toutes les 4 secondes

Note : Il est possible de lire les fichiers .pcapng.gz directement avec Wireshark.

Bouygues a basculé tout en DSCP 0 en 2019/2020 pour se conformer à la neutralité du net.

Code pour tager en DSCP 10 sur un serveur :
Code: [Sélectionner]
# Connexions sortantes TCP
/usr/sbin/iptables  -t mangle -A OUTPUT -p tcp --dport 53:32767 -j DSCP --set-dscp 10
/usr/sbin/ip6tables -t mangle -A OUTPUT -p tcp --dport 53:32767 -j DSCP --set-dscp 10

# Connexions sortantes UDP
/usr/sbin/iptables  -t mangle -A OUTPUT -p udp --dport 53 -j DSCP --set-dscp 10
/usr/sbin/ip6tables -t mangle -A OUTPUT -p udp --dport 53 -j DSCP --set-dscp 10

# Connexions entrantes TCP
/usr/sbin/iptables  -t mangle -A OUTPUT -p tcp --sport 53:32767 -j DSCP --set-dscp 10
/usr/sbin/ip6tables -t mangle -A OUTPUT -p tcp --sport 53:32767 -j DSCP --set-dscp 10

# Connexions entrantes UDP
/usr/sbin/iptables  -t mangle -A OUTPUT -p udp --sport 53 -j DSCP --set-dscp 10
/usr/sbin/ip6tables -t mangle -A OUTPUT -p udp --sport 53 -j DSCP --set-dscp 10
/usr/sbin/iptables  -t mangle -A OUTPUT -p udp --sport 8080 -j DSCP --set-dscp 10
/usr/sbin/ip6tables -t mangle -A OUTPUT -p udp --sport 8080 -j DSCP --set-dscp 10
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: renaud07 le 19 août 2025 à 19:08:08
De mon côté, j'ai toujours le trafic en AF22 (0x50), mais on dirait que c'est pour tout, il n'y a pas de distinction (de ce que j'ai vérifié en tout cas), donc peut-être que ça revient au même que si tout était retagué en CS0. C'est peut-être un moyen de distinguer le trafic mobile du fixe plus loin sur le réseau ?

Exemple pour le DNS :
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 19 août 2025 à 19:31:05
Sur le fixe grand-public, c'est DSCP 0.

C'est peut-être pour que sur le backbonne Bouygues, dans le cas (qui ne devrait pas se produire) d'une saturation, le trafic mobile soit prioritaire sur le trafic fixe.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: Raraph84 le 02 septembre 2025 à 10:35:08
Salut !
J'observe en effet le même soucis entre deux lignes FTTH Sosh (Orange) via Wireguard, on va les noter ligne 1 et 2

La ligne 1, située dans le Vaucluse, a utilisé la Livebox 5 dans le passé, tout fonctionnait très bien, pas de limitation etc, depuis plusieurs mois, je me suis passé de la Livebox, en mettant mon propre routeur Debian à la place, avec un ONT externe
A l'heure actuelle, aucune limitation en Wireguard vers un VPS que je possède

La ligne 2, toute récente (je viens d'emménager), située en périphérie de Lyon, utilise pour le moment la nouvelle Livebox S, et là, surprise, je me rend compte que ma ligne est inutilisable avec un Wireguard entre mes deux lignes, et dans les deux sens (PC <-> Livebox S <-> Backbone Orange <-> Routeur Debian)

Je fais donc un iperf à travers le tunnel, je me rend compte en effet d'un bridage à ~5mbps, je fais un iperf hors tunnel, en UDP (pour essayer de ressembler à Wireguard), aucun problème à ce niveau là, je sature mes lignes

Sur la ligne 2, aucun soucis non plus avec le Wireguard vers mon VPS
J'attends mon ONT bien gentiment envoyé par le support Sosh pour pouvoir faire des tests sans la Livebox sur la ligne 2
J'ai fait pour le moment tout les tests en IPv4, et je n'ai rien regardé niveau DSCP
N'hésitez pas à me dire si vous avez besoin que je fasse des tests supplémentaires
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 02 septembre 2025 à 18:37:21
Le flux limité à 5 Mb/s est DSCP 0 ?

Ce serait le protocole qui déclenche la limitation ?

Tu as testé Ligne 2 (Livebox S) avec un trafic Wireguard vers ton VPS ?
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: Raraph84 le 02 septembre 2025 à 20:05:52
Re,
Comme dit plus tôt j'ai en effet fait un test entre ma nouvelle ligne et mon VPS, pas de soucis dans les deux sens, le soucis est uniquement entre les deux lignes Orange

Aussi, j'avais dû mal regarder plus tôt, j'observe la limite de 5mbps uniquement depuis la Livebox S vers mon routeur fibre
PC -> Livebox S -> Backbone Orange -> Routeur fibre ----> 5mbps
Dans l'autre sens j'ai pas l'impression d'être limité par le réseau, uniquement pas le CPU de mes équipements, j'atteins largement >100mbps

J'ai aussi fait des tests pour la DSCP:
J'ai connecté un Raspberry Pi à la Livebox S de la nouvelle ligne (c'est le seul appareil que j'avais sous la main et sur lequel je pouvais mettre Linux dessus pour faire des tests)
Puis j'ai établi un tunnel Wireguard entre le Raspberry Pi et mon routeur fibre de l'autre ligne
Raspberry Pi <-> Livebox S <-> Backbone Orange <-> Routeur fibre

Ensuite j'ai effectué plusieurs iperfs, en UDP, plus simple à visualiser dans les captures de packets, pas de packets TCP non nécessaires

10mbps, assez pour saturer la limite de 5mbps:
Code: [Sélectionner]
iperf3 -c 10.0.0.1 -b 10000000 -u -t infOn observe bien la saturation des 5mbps

J'ai ensuite démarré des captures de packets des deux côtés:
Côté Raspberry Pi:
Code: [Sélectionner]
tcpdump -ni eth0 port 51820 -vvvCôté routeur fibre:
Code: [Sélectionner]
tcpdump -ni eth0.832 port 51820 -vvv
Je lance ensuite un iperf plus calme, 100kbps pour observer les packets:
Code: [Sélectionner]
iperf3 -c 10.0.0.1 -b 100000 -u -t infRaspberry Pi -> Livebox S -> Backbone Orange -> Routeur fibre
En sortie du Raspberry on a des:
Code: [Sélectionner]
18:44:48.700989 IP (tos 0x0, ttl 64, id 30523, offset 0, flags [none], proto UDP (17), length 1468)
    192.168.6.100.43484 > yyy.51820: [bad udp cksum 0xd2a2 -> 0xb14e!] UDP, length 1440Et en entrée du réseau Orange de l'autre côté on reçois:
Code: [Sélectionner]
19:44:48.734173 IP (tos 0x88, ttl 57, id 30523, offset 0, flags [none], proto UDP (17), length 1468)
    xxx.43484 > yyy.51820: [udp sum ok] UDP, length 1440On observe un ajout de 0x88

Dans l'autre sens, là où on semble pas bridé:
Code: [Sélectionner]
iperf3 -c 10.0.0.1 -b 100000 -u -t inf -RRouteur Fibre -> Backbone Orange -> Livebox S -> Raspberry Pi
En sortie du réseau Orange on envoie:
Code: [Sélectionner]
19:50:21.081316 IP (tos 0x0, ttl 63, id 21910, offset 0, flags [none], proto UDP (17), length 1468)
    yyy.51820 > xxx.43484: [bad udp cksum 0x2abe -> 0x2aea!] UDP, length 1440Et de l'autre côté, en entrée du Raspberry on reçois:
Code: [Sélectionner]
18:50:21.085153 IP (tos 0x80, ttl 56, id 21910, offset 0, flags [none], proto UDP (17), length 1468)
    yyy.51820 > 192.168.6.100.43484: [udp sum ok] UDP, length 1440On observe un ajout de 0x80

J'ai aussi fait un test hors Wireguard, on observe bien que je ne suis pas bridé, et côté packets on a:
Raspberry Pi -> Livebox S -> Backbone Orange -> Routeur fibre
En sortie du Raspberry on envoie:
Code: [Sélectionner]
18:59:52.314264 IP (tos 0x0, ttl 64, id 43019, offset 0, flags [DF], proto UDP (17), length 1476)
    192.168.6.100.59112 > yyy.5201: UDP, length 1448Et en entrée du réseau Orange de l'autre côté on reçois:
Code: [Sélectionner]
19:59:52.319163 IP (tos 0x0, ttl 57, id 43019, offset 0, flags [DF], proto UDP (17), length 1476)
    xxx.59112 > yyy.5201: UDP, length 1448On observe que la TOS n'a pas changée

Je ne me suis jamais penché sur la DSCP donc je vous laisse essayer de déduire quelque chose par vous même
Bonne soirée :)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 04 septembre 2025 à 15:15:16
Bonjour @Raraph84

Tu aurais la capture de l'établissement du tunnel WireGuard ?
Si wireGuard à un moment joue avec le DSCP cela peut être la cause de ce que tu as.

En tout cas on regarde aussi de notre coté avec les gars des LB

LeVieux

Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 04 septembre 2025 à 15:22:49
Bonjour @Raraph84

Question : sur ton routeur fibre, sais tu faire une remarquage DSCP à 0 sur tous les paquet entrant de ton LAN à direction du WAN.
Si cela est possible et que cela corrige, on tient le bon bout ... avec cela je saurais faire analyser coté boxe.
Voir vous rajouter une spec coté de l'interface réseau protocolaire 2023 :)


LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: Raraph84 le 04 septembre 2025 à 16:26:30
Salut,

J'ai fait une capture de packet pendant l'établissement de la connexion Wireguard, suivi d'un ping ICMP dans le tunnel:
Pour rappel on a Raspberry Pi -> Livebox S -> Backbone Orange -> Routeur fibre

Côté Raspberry Pi on a:
Code: [Sélectionner]
root@Raspberry-Pi-Appart:~# tcpdump -ni eth0 port 51820 -v
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:44:39.073214 IP (tos 0x88, ttl 64, id 42973, offset 0, flags [none], proto UDP (17), length 176)
    192.168.6.100.57306 > yyy.51820: UDP, length 148
14:44:39.083369 IP (tos 0x80, ttl 56, id 37129, offset 0, flags [none], proto UDP (17), length 120)
    yyy.51820 > 192.168.6.100.57306: UDP, length 92
14:44:39.086116 IP (tos 0x0, ttl 64, id 42976, offset 0, flags [none], proto UDP (17), length 60)
    192.168.6.100.57306 > yyy.51820: UDP, length 32

14:45:36.710332 IP (tos 0x0, ttl 64, id 51364, offset 0, flags [none], proto UDP (17), length 156)
    192.168.6.100.57306 > yyy.51820: UDP, length 128
14:45:36.725424 IP (tos 0x80, ttl 56, id 40030, offset 0, flags [none], proto UDP (17), length 156)
    yyy.51820 > 192.168.6.100.57306: UDP, length 128
Et côté routeur fibre on a:
Code: [Sélectionner]
root@Home-Router-VPS:~# tcpdump -ni eth0.832 port 51820 and host xxx -v
tcpdump: listening on eth0.832, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:44:39.076520 IP (tos 0x0, ttl 57, id 42973, offset 0, flags [none], proto UDP (17), length 176)
    xxx.57306 > yyy.51820: UDP, length 148
15:44:39.077199 IP (tos 0x88, ttl 63, id 37129, offset 0, flags [none], proto UDP (17), length 120)
    yyy.51820 > xxx.57306: UDP, length 92
15:44:39.089893 IP (tos 0x88, ttl 57, id 42976, offset 0, flags [none], proto UDP (17), length 60)
    xxx.57306 > yyy.51820: UDP, length 32

15:45:36.718909 IP (tos 0x88, ttl 57, id 51364, offset 0, flags [none], proto UDP (17), length 156)
    xxx.57306 > yyy.51820: UDP, length 128
15:45:36.719345 IP (tos 0x0, ttl 63, id 40030, offset 0, flags [none], proto UDP (17), length 156)
    yyy.51820 > xxx.57306: UDP, length 128
Donc on observe:
Le premier packet (Raspberry Pi -> Routeur Fibre), part avec 0x88 et arrive avec 0x00 (on soupçonne remis à 0 par la Livebox)
Le second packet (Routeur Fibre -> Raspberry Pi), part avec 0x88 et arrive avec 0x80
Et le troième packet (Raspberry Pi -> Routeur Fibre), part avec 0x00 et arrive avec 0x88

Pour le ping on observe:
Le premier packet (Raspberry Pi -> Routeur Fibre), part avec 0x00 et arrive avec 0x88
Le second packet (Routeur Fibre -> Raspberry Pi), part avec 0x00 et arrive avec 0x80

Le soucis doit donc probablement venir du second packet, partant vers le réseau Orange avec 0x88

Pour tester, je tente d'appliquer une règle pour remettre la dscp à 0 sur le trafic sortant (j'applique uniquement sur le port Wireguard 51820 pour éviter de rien casser d'autre pour le moment)
Code: [Sélectionner]
nft add table netdev filter
nft add chain netdev filter egress { type filter hook egress device eth0.832 priority 0; }
nft add rule netdev filter egress udp sport 51820 ip dscp set 0
Je coupe et je relance la connexion Wireguard et TADA ! ça fonctionne ! j'atteins sans problème >100mbps
Je pense donc qu'il faudra mettre à jour la conformité protocolaire
Bonne fin de journée ! :)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 04 septembre 2025 à 16:33:01
Super test !!

Cela confirme ce que je soupçonnais dans le comportement de la LB. En fait sur le négo SYN / SYNACK / ACK ou le premier triplet d'échange de paquets UDP y'a un truc qui est mis en place et le reste du flux est retagué avec le DSCP négocié dans les 3 premiers Pkts.

Je vais aller en causer de ce pas au gars des boxe.

Par contre il va me rester la question du remarquage en IPv6 vers les autres opérateurs. Là j'ai encore un truc à regarder (enfin faire regarder, j'ai pas le pouvoir de voir cette partie là)

LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: bigboo le 12 septembre 2025 à 15:06:33
Bonjour,
Je suis concerné par ce problème de limitation de débit à 5mbs pour un tunnel Wireguard entre 2 maisons fibrées Sosh, la mienne avec un routeur Openwrt configuré avec le tutoriel en première page du topic ci-dessous, et l'autre avec une livebox 5.

est-ce que vous pouvez confirmer que le tutoriel en première page permet de bien configurer les priorités à 0 pour Openwrt ?
https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: unipo le 25 septembre 2025 à 09:51:34
Même limitation de mon côté, si je comprends bien le correctif devrait venir côté orange?
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: Raraph84 le 25 septembre 2025 à 10:19:35
Salut !
De ce qu'on a observé, le problème vient de ton routeur
Normalement si tu remets la DSCP à 0 en sortie vers Orange ca devrait régler le soucis
Si tu n'as pas de routeur custom (Livebox ou mobile des deux côtés), le soucis viens bien d'Orange, mais je pense pas que ca soit le cas
Bonne journée !
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 25 septembre 2025 à 10:42:37
Hello

J'ai fait faire des tests en interne Orange avec des LB et des tunnels WireGuard :
- les LB remettent bien la CoS à 0 en sortant
- donc pas de limitation de débit dès que l'on est sur des LB (plusieurs combinaisons ont été validées) .

Le remarquage de la CoS / DSCP à ZERO pour tout ce qui ne concerne PAS l'établissement de la session est IMPERATIF si vous avez un routeur autre que LB

LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: simon le 25 septembre 2025 à 11:23:26
Citation de: levieuxatorange le 25 septembre 2025 à 10:42:37
Le remarquage de la CoS / DSCP à ZERO pour tout ce qui ne concerne PAS l'établissement de la session est IMPERATIF si vous avez un routeur autre que LB

Quel serait l'intérêt d'avoir les paquets concernant l'établissement de la session (TCP handshake je suppose, mais potentiellement les premiers paquets d'établissement d'un tunnel wireguard aussi) à une CoS != 0 ?
Éviter la perte de paquet d'un SYN et gagner quelques ms ? À mon sens, autant marquer tout le trafic venant du LAN en CoS 0 et ne pas s'embêter à sur-optimiser.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 25 septembre 2025 à 11:32:26
Citation de: simon le 25 septembre 2025 à 11:23:26
Quel serait l'intérêt d'avoir les paquets concernant l'établissement de la session (TCP handshake je suppose, mais potentiellement les premiers paquets d'établissement d'un tunnel wireguard aussi) à une CoS != 0 ?
Éviter la perte de paquet d'un SYN et gagner quelques ms ? À mon sens, autant marquer tout le trafic venant du LAN en CoS 0 et ne pas s'embêter à sur-optimiser.
Je suis en phase, aucun et il faut tout retaguer ce qui vient du LAN à ZERO  ... Mais j'ai pas regardé les dernière RFC sur les notions de QoS. Si cela se trouve y'a des catégories par défaut qui ont été préconisée.

LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 25 septembre 2025 à 11:40:42
Citation de: levieuxatorange le 25 septembre 2025 à 10:42:37
J'ai fait faire des tests en interne Orange avec des LB et des tunnels WireGuard :
- les LB remettent bien la CoS à 0 en sortant
- donc pas de limitation de débit dès que l'on est sur des LB (plusieurs combinaisons ont été validées) .
Si les Livebox remettent la CoS à 0, je pense que ce n'est pas le cas des Flybox 2 Wi-Fi 6 (box 5G).

Je n'ai pas testé le dernier modèle Wi-Fi 7, mais si cela n'a pas été mis dans le cahier des charges, cela ne doit pas avoir changé.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: Sylvain92 le 26 septembre 2025 à 14:45:42
Bonjour,

Je partage mon expérience (pro). Nous avons eu dans notre groupe un incident assez complexe il y a quelques mois. Le trafic entre la région Microsoft West Europe et nos routeur CPE (GTT) sur Paris s'est retrouvé du jour au lendemain en CS1 (il était en CS0 avant).
Le trafic depuis les autres régions était bon. Si vous ne gérez pas la QoS en interne sur vos routeurs, vous ne vous en apercevez pas, mais nous oui... les paquets en CS1 partaient à la poubelle à 99%...

Ni l'opérateur ni Microsoft n'a été capable de trouver à quel endroit ces paquets étaient remark, notre seule solution a été de désactiver la QoS pour le CS1.

En faisant des captures, on a pu s'appercevoir que les classes DSCP étaient conservées pour 99% du trafic chez GTT (On peut voir aisément du AF21, AF41, EF..en entrant et sortant). Chez Colt, 99% est remark en CS0, tout comme mon ancienne fibre SFR GP. C'est donc très variable d'un opérateur à l'autre.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: tvvmongeek le 28 septembre 2025 à 16:10:39
Citation de: levieuxatorange le 25 septembre 2025 à 10:42:37
Hello

J'ai fait faire des tests en interne Orange avec des LB et des tunnels WireGuard :
- les LB remettent bien la CoS à 0 en sortant
- donc pas de limitation de débit dès que l'on est sur des LB (plusieurs combinaisons ont été validées) .

Le remarquage de la CoS / DSCP à ZERO pour tout ce qui ne concerne PAS l'établissement de la session est IMPERATIF si vous avez un routeur autre que LB

LeVieux

Bonjour,

Pour info, je viens d'avoir le cas entre deux FTTH Orange/Sosh, les deux disposant d'une livebox (pas de bypass).

Contexte :
Tunnel Wireguard entre deux Mikrotik situés derrière les livebox (setup avec la fonctionnalité "DMZ" des LB), limitation à 5Mbit/s tout pile.
L'un des côtés a une LB4, l'autre une LB5, et les deux étaient à jour (j'ai vérifié avant de toucher quoi que ce soit).

Ce que j'observais c'est que j'envoyais des paquets taggués CS0 et que je recevais des paquets CS4 à l'autre extrémité (comportement symétrique sur les deux liaisons), mais j'ai vu mes Mikrotik faire un peu de CS4 pendant la phase de négo.

Du coup, maintenant je force tout ce qui sort à sortir en CS0 -> problem solved, plus de limitation de débit sur le tunnel, et ce qui part en CS0 d'un côté arrive CS0 de l'autre.

Bon dimanche !
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 29 septembre 2025 à 09:11:01
Citation de: tvvmongeek le 28 septembre 2025 à 16:10:39
mais j'ai vu mes Mikrotik faire un peu de CS4 pendant la phase de négo.
Bonjour

ça c'est pas normal, la LB aurait du retaguer le flux en CS0 à l'interface LAN de la LB avant de possuer le Pkts sur le WAN !!!

Go vers les boxe pour debug. Merci !!

LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: unipo le 30 septembre 2025 à 18:14:36
Retour de l'on côté,
À peu de chose près même setup que tvvmongeek.
Lien wireguard , les clients derrière livebox 5 ont un débit montant bloqué à 5Mbit/s.
Forcer la CoS sur un router (OpenWRT) permet de corriger le tir. Chose bien moins commode sur les différents clients windows/iOS/Android.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: Max le 30 septembre 2025 à 19:23:49
Et moi j'ai le problème avec un tunnel WireGuard entre une Livebox 7 W6E et un iPhone 17 Pro Max connecté sur le réseau mobile Orange
Et aussi entre une Livebox 6 et ce même iPhone...
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 01 octobre 2025 à 09:43:44
Hello tous

En attendant d'avoir une réponse de la part des boxes, si vous savez forcer sur votre serveur WireGard le remarquage de la CoS / DSCP à ZERO faite le !!

Y'a rien dans les paramètre du client Android s'approchant de cela..

Je viens de regarder la spec du protocol WireGuard ... Honnetement, là c'est de la faute de WireGuard ...
Code: [Sélectionner]
All handshake packets have a DSCP value of 0x88 (AF41), so that these packets are the least likely to be dropped
C'est volontaire de WireGuard qui tague ses paquets en VOIX pour "s'assurer que cela ne soit pas jeté par le réseau".

Sauf que du coup, ben c'est de la VOIX, donc limité au débit VOIX .... (5 Mb/s)

LeVieux

Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: gg40530 le 01 octobre 2025 à 10:45:52
C'est pour les handshake, les data sont concernées ?
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: Harvester le 01 octobre 2025 à 10:46:45
Il y a eu une proposition de patch pour supporter des valeurs DSCP différentes sur la mailing list, mais ça n'a jamais été mergé. Peut être que si le patch s'applique proprement sur les versions actuelles (le patch est de 2019) et que quelqu'un veut recompiler et tester...

https://lists.zx2c4.com/pipermail/wireguard/2019-March/004026.html
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: unipo le 01 octobre 2025 à 10:53:52
Effectivement,
Un client Android établissant un handshake en données mobile puis basculant sur le wifi de la livebox 4, le tunnel restant activé, le débit n'est pas affecté.
Puis toujours sous le wifi de la box, désactiver puis réactiver le tunnel limite le débit montant à 5Mbit/s.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 01 octobre 2025 à 10:54:50
Citation de: gg40530 le 01 octobre 2025 à 10:45:52
C'est pour les handshake, les data sont concernées ?
Je suis en train de me fournir la spec des LB.
Je crois que les premiers Pkts fixent la QoS de tout le flux, la LB remarquant le flux à ce qui est négocié dans le handshake

Donc même si WG repasse en DSCP 0 après, tout est remarqué par la LB en DSCP AF41 (CS4 donc) avec la limitation constatée.

Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 01 octobre 2025 à 10:59:37
Ok, cela expliquerait la limitation avec SSH ou les paquets de données sont tagés en DSCP 0, mais limités à 5 Mb/s.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: kgersen le 01 octobre 2025 à 13:41:53
Citation de: levieuxatorange le 01 octobre 2025 à 10:54:50
Donc même si WG repasse en DSCP 0 après, tout est remarqué par la LB en DSCP AF41 (CS4 donc) avec la limitation constatée.

ca ressemble a une opti faspath du NAT mal codé (il garde la prio du 1er paquet) ? y'a le meme souci en IPv6?
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: unipo le 01 octobre 2025 à 14:17:53
@kgersen
Tout mes liens wireguard sont IPv6.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 01 octobre 2025 à 14:28:15
Non, c'est pas un bug (au sens mauvais codage)

C'est une question de gestion de la QoS et à une philosophie qui est que sur un flux, il est d'une  COS unique et consistante tout au long de son existence.

Le "je me déguise en VoIP pour le 3 way HandShake puis je repasse en CS0", ben ... dans notre vision c'est pas bon ... et on garde la QoS négociée dans le 3 way HandShake .... donc on hérite de la limitation de débit des classes prioritaires .. limitations établies pour tout un tas de raisons reglementaires (coucou @ARCEP) et sécurité (coucou @ANSSI) ..





Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: kgersen le 01 octobre 2025 à 16:26:40
Citation de: levieuxatorange le 01 octobre 2025 à 14:28:15
Non, c'est pas un bug (au sens mauvais codage)

C'est une question de gestion de la QoS et à une philosophie qui est que sur un flux, il est d'une  COS unique et consistante tout au long de son existence.

Le "je me déguise en VoIP pour le 3 way HandShake puis je repasse en CS0", ben ... dans notre vision c'est pas bon ... et on garde la QoS négociée dans le 3 way HandShake .... donc on hérite de la limitation de débit des classes prioritaires .. limitations établies pour tout un tas de raisons reglementaires (coucou @ARCEP) et sécurité (coucou @ANSSI) ..

ca veut donc dire que ce n'est pas stateless donc, y'a un tracking des connections meme en IPv6 , la décision n'est pas paquet par paquet ? donc une inspection pour savoir si c'est de l'UDP ou du TCP , etc ?

Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 01 octobre 2025 à 16:38:39
Citation de: kgersen le 01 octobre 2025 à 16:26:40
ca veut donc dire que ce n'est pas stateless donc, y'a un tracking des connections meme en IPv6 , la décision n'est pas paquet par paquet ? donc une inspection pour savoir si c'est de l'UDP ou du TCP , etc ?

Inspection, le terme est un peu fort :)
Comme, tu as un firewall dans les LB qui est statefull , à l'ouverture du flux la gestion DSCP est mise en place (que ce soit TCP ou UDP, en Ipv4 ou IPv6).

Le reste du flux n'est plus regardé et traité directement par le hard. Et donc sans changement du DSCP.

Et c'est justement le soucis, comme c'est pas traité paquet par paquet mais flux par flux pour atteindre les perfs, les changement de COS sur un flux sont pas vu ..

LeVieux

Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: renaud07 le 01 octobre 2025 à 16:50:20
C'est quand même assez moyen ce genre de traitement... Les autres FAI font pareil ?

Concernant le débit, tout ce qui est marqué autre que CS0 est limité à 5 Mb/s ou y'a des exceptions ? Genre en EF par exemple ?
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: kgersen le 01 octobre 2025 à 17:02:25
Citation de: levieuxatorange le 01 octobre 2025 à 16:38:39
Inspection, le terme est un peu fort :)
Comme, tu as un firewall dans les LB qui est statefull , à l'ouverture du flux la gestion DSCP est mise en place (que ce soit TCP ou UDP, en Ipv4 ou IPv6).

Le reste du flux n'est plus regardé et traité directement par le hard. Et donc sans changement du DSCP.

Et c'est justement le soucis, comme c'est pas traité paquet par paquet mais flux par flux pour atteindre les perfs, les changement de COS sur un flux sont pas vu ..


du coup si on désactive le firewall ca regle le souci ?! ;)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 01 octobre 2025 à 17:23:13
Si c'est sur le même type que cette veille box Sagem, le CPU n'est pas en mesure de faire passer tous les paquets par le NAT/FIREWALL/policies et pour le décharger, on ne passe une seule fois pour chaque flux.

La box FTTH Sagem F@st3190w était saturé avec même pas 20 Mb/s quand on passait tous ses paquets par le CPU (et avec le watchdog elle redémarrait automatiquement).

C'est un sujet que j'ai traité il y a 20 ans, quand les connexions FTTH sont passées de 10 Mb/s à 20 Mb/s  ;D
On pouvait monter à 20 Mb/s, mais pas sur le port 80 à l'époque.

Citation de: vivien le 06 juin 2011 à 09:39:07
Voici la réponse du chef de projet de CPE FTTH Sagem le 31 juillet 2006 :

Explication des performances non satisfaisantes vues sur un téléchargement HTTP.

Fonctionnement des Accélérateurs:
Lorsque l'utilisateur lance un téléchargement TCP/UDP, les premiers paquets qui sont responsables de l'établissement de la connexion passent par le CPU(chemin classique :NAT/FIREWALL/policies...), une fois le lien est établie tous les prochains paquets passeront par les accélérateurs (chemin rapide). Les accélérateurs n'analyse que l'entête TCP/IP du paquet et pas son contenue.

Cas d'un transfert de texte par MSN MESSENGER:
Lorsque un client utilise MSN MESSENGER pour chatter se dernier se connecte sur le port 1863/TCP à un serveur de chez Microsoft. dans ce cas le Nat est traversé proprement et le message retour est bien identifié par le Firewall du F@st3374.

Cas d'un transfert de vidéo par MSN MESSENGER :
Les problèmes arrivent lorsque le client demande une connexion vocale/video. Dans ce cas, MSN MESSENGER va demander au serveur de choisir un autre port pour faire passer le flux vidéo. Et le problème c'est que ce port est choisie au hasard entre le port TCP/9000 et TCP/65535. Pour que le flux
vidéo provenant du serveur soit identifier par le firewall du F@st3374 et qu'il soit forwardé correctement, tous les paquets msn( TCP et destPort/srcPort = 1863) passeront par une fonction de traitement supplèmentaire qui permet d'analyser les contenues des paquets en plus de leurs entêtes TCP/IP.
Dans ce cas le flux vidéo passera par les accélérateurs(chemin rapide) mais tous les paquets msn(TCP-port =1863) passeront par le CPU(chemin classique).

Cas du port 80:
Si pour une raison ou pour une autre le MSN MESSENGER n'arrive pas à se connecter au serveur Microsoft sur le port 1863 alors il retombe sur le port 80 en faisant du HTTP tunneling. Affin de supporter ce cas bien particulier le F@st3374 fait passer touts les paquets HTTP(port 80) par le même chemin par lequel passe les paquets msn (port 1863).

Solution immédiate :
Ne supporter que le chat en mode texte dans le cas où le client MSN MESSENGER fait du backup sur le port 80. Et si dans ce cas particulier l'utilisateur veut faire du Chat en mode vidéo il doit installer UPNP sur son poste qui va s'en charger  de communiquer avec le Firewall du F@st3374 pour ouvrir les bons ports.

Je reste à votre disposition pour tout éclaircissement supplèmentaire.

Cordialement.

A noter que le même phénomène est utilisé sur le port 21 pour le FTP.

Note : Les box équipées de Watchdog reboot lors d'un transfert HTTP à 20 Mb/s ou plus, le CPU étant utilisé à 100%, le watchdog est là pour rétablir la situation via un reboot
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 01 octobre 2025 à 17:36:50
Citation de: kgersen le 01 octobre 2025 à 17:02:25
du coup si on désactive le firewall ca regle le souci ?! ;)

Il n'est JAMAIS désactivé :)
C'est juste que les règles "clientes" passent en open bar quand tu coches la case "désactivé"

Le FW est toujours en place pour protéger la LB en elle même

Et donc qualifier les flux et le DSCP
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 01 octobre 2025 à 17:44:45
Citation de: renaud07 le 01 octobre 2025 à 16:50:20
C'est quand même assez moyen ce genre de traitement... Les autres FAI font pareil ?
Ca c'est un choix d'ingénierie de bout en bout.
D'autres FAI considèrent que tout trafic qui vient du client est remarqué en CS0. Donc aucune priorisation TV ou VoIP.
Pour des boxe en mode BRIDGE, on ne sait pas ce qui est fait sur le DSCP coté WAN.
Tout est une question de design de bout en bout. Et là, chaque FAI (petit ou gros) a son propre design, y'a pas de bonnes ou mauvaises règles.


Citation de: renaud07 le 01 octobre 2025 à 16:50:20
Concernant le débit, tout ce qui est marqué autre que CS0 est limité à 5 Mb/s ou y'a des exceptions ? Genre en EF par exemple ?

Y'a 4 classes je pense sur le réseau orange RBCI, plus la classe est prioritaire, plus le débit est limité à l'accès.
Faudrait que je retrouve les 4 classes et les débits associés, mais je crois que des gens ici l'avaient trouvé par test.

Mais retenir : CS0 PARTOUT et vous aurez accès à 100% du débit (en gestion égalitaire de la congestion avec les autres demandeurs) ...

LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: renaud07 le 01 octobre 2025 à 17:57:04
Citation de: levieuxatorange le 01 octobre 2025 à 17:44:45
Ca c'est un choix d'ingénierie de bout en bout.
D'autres FAI considèrent que tout trafic qui vient du client est remarqué en CS0. Donc aucune priorisation TV ou VoIP.
Pour des boxe en mode BRIDGE, on ne sait pas ce qui est fait sur le DSCP coté WAN.
Tout est une question de design de bout en bout. Et là, chaque FAI (petit ou gros) a son propre design, y'a pas de bonnes ou mauvaises règles.

J'ai mal compris de toute évidence, je pensais que ces règles émanaient de l'ACREP/ANSSI. C'est seulement la "définition" des classes et pas la manière dont le trafic est catégorisé qui est laissé à l'appréciation du FAI ?

Citation de: levieuxatorange le 01 octobre 2025 à 17:44:45
Y'a 4 classes je pense sur le réseau orange RBCI, plus la classe est prioritaire, plus le débit est limité à l'accès.
Faudrait que je retrouve les 4 classes et les débits associés, mais je crois que des gens ici l'avaient trouvé par test.

Mais retenir : CS0 PARTOUT et vous aurez accès à 100% du débit (en gestion égalitaire de la congestion avec les autres demandeurs) ...

Merci  :)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: daleksek le 01 octobre 2025 à 18:10:58
Citation de: daleksek le 31 juillet 2025 à 11:41:55
J'utilise IPQoS cs0 depuis quelques temps sinon c'est bridé,
Je suis en IPV4 only,

Transferts de fichier via SSH, FTTH Bouygues récupère des fichiers sur FTTH Orange :
Si le paramètre IPQoS cs0 n'est pas présent, je plafonne à environ 5 mbits d'upload
Si j'utilise tailscale qui fonctionne avec wireguard, je n'ai plus la limite, la seule limite c'est le CPU de la machine, je montes à 70-80Mo/s d'upload
Si le paramètre IPQoS cs0 est présent, la connexion en direct n'est plus bridée, j'atteins bien les 1 Gbits d'upload,
Je viens de passer au XGS-PON côté Orange, le paramètre n'est actuellement pas présent (dans /etc/ssh/sshd_config) sur mon serveur linux côté Orange et en testant je n'ai pas eu le bridage, donc il y a peut être eu une modif côté NRO/PM (je n'ai pas pensé à faire le test quand j'avais encore la LB6, lorsque mon PM à été migré au XGSPON), de la Livebox 7 ou peut être sur mon routeur j'ai touché quelque chose.
La ligne Bouygues est à 2Gbits, durant le transfert j'ai pu monter à 1.7Gbits dans le sens Orange -> Bouygues

Edit : Après vérification des graphs réseau, ça tournait à 9.98mbits juste avant que je ne branche la LB7, donc la LB6 (même après la migration du PM en XGS) était limitée.
Je n'avais encore rien touché sur mon routeur, donc ça vient soit du XGSPON ou de la LB7 qui doivent tagguer correctement les packets.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 01 octobre 2025 à 18:21:21
Citation de: renaud07 le 01 octobre 2025 à 17:57:04
J'ai mal compris de toute évidence, je pensais que ces règles émanaient de l'ACREP/ANSSI.
Je m'exprime à titre personnel.

Non, le règlement européen sur la neutralité du net, c'est plutôt au FAI de tout mettre tout le trafic internet au même niveau.

Maintenant, c'est un sujet complexe, il y a des exceptions (comme par exemple pour la box TV de l'opérateur pour les flux vidéo UDP qui nécessitent une priorisation pour ne pas être dégradé, pour le respect des obligations légales, pour l'intégrité du réseau, pour les situations exceptionnelles et temporaires de congestions,...) et il est possible que ce que fait Orange rentre dans les exceptions.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: renaud07 le 01 octobre 2025 à 18:52:16
Oui sans doute. Et pour ce qui est de la priorisation TV/VoIP sur le reste c'est un peu normal, sinon bonjour la qualité.

Maintenant qu'on le sait faudra faire attention...
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 01 octobre 2025 à 21:00:00
La priorisation de la voix est surtout importante en ADSL. Tous les opérateurs ne priorisaient pas les flux en ADSL (je pense à Bouygues Telecom sur la zone dans laquelle les DSLAM SFR étaient utilisés par exemple, à l'époque où cela existait) et cela pouvait se remarquer en cas de téléchargement important réalisé en même temps qu'un appel.

En FTTH, c'est presque inutile et certains opérateurs ne priorisent pas la voix de la box sur leur propre réseau.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: jerome34 le 01 octobre 2025 à 21:06:31
Citation de: vivien le 01 octobre 2025 à 21:00:00

En FTTH, c'est presque inutile et certains opérateurs ne priorisent pas la voix de la box sur leur propre réseau.
Qui ? Source ? Cela semble quand même assez étonnant.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: Max le 01 octobre 2025 à 21:22:22
Je viens de faire d'autres tests de mon côté :

Mon PC connecté en partage de connexion sur mon iPhone (Orange 180 Go 5G+), j'établie mon tunnel WireGuard en IPv4 vers ma Livebox V7 (sur mon PC et non pas mon iPhone), et avec WireShark je vois bien les paquets sortir en DSCP 0 (destination port 51820), en revanche ceux qui m'arrivent (source port 51820) sont tagués en DSCP 18 (AF21) :o

Nouveau test, toujours avec mon PC, connecté cette fois en partage de connexion sur mon Android (Sosh 150 Go 5G), j'établie mon tunnel WireGuard en IPv4 vers ma Livebox 7 sur mon PC, et avec WireShark je vois bien les paquets sortir en DSCP 0 (destination port 51820), et ceux qui m'arrivent (source port 51820) sont eux aussi tagués en DSCP 0 et j'ai plus la limitation de débit à 5 Mbps... 8)

Dernier test, toujours avec mon PC, connecté sur mon iPhone mais avec Forfait Free 19.99€, j'établie mon tunnel WireGuard en IPv4 vers ma Livebox 7 sur mon PC, et avec WireShark je vois bien les paquets sortir en DSCP 0 (destination port 51820), et ceux qui m'arrivent (source port 51820) sont eux aussi tagués en DSCP 0 et je n'ai pas non plus de limitation de débit :)

J'ai testé de taguer en DSCP 0 depuis le serveur WireGuard, un MikroTik connecté derrière la Livebox 7, mais ça n'a aucune influence car les paquets partent bien en DSCP 0 mais sont retagués à priori plus loin en DSCP 18 :(

Comment expliquer cette différence de DSCP pour les paquets provenant de mon VPN entre iPhone et Android tous deux chez Orange ? Et qu'il n'y a pas de problème non plus avec mon iPhone et ma SIM Free Mobile ?

Si quelqu'un d'autre chez Orange en 5G avec un iPhone peut confirmer être concerné aussi par cette limitation ?

J'ai les traces WireShark de ces 3 tests @levieuxatorange si ça t'intéresse...

Merci !
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: renaud07 le 01 octobre 2025 à 22:16:41
Ça ne serait pas le forfait avec priorisation pour Orange ? Ou c'est peut-être spécifique à la SA...

C'est la même chose avec le reste du trafic ? Et côté mikrotik, les paquets dans le sens PC > serveur arrivent en DSCP 0 ?
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: Max le 01 octobre 2025 à 22:50:15
Effectivement, bien vu !

Je viens de faire le test avec ma SIM Sosh 150 Go 5G dans mon iPhone, et tout est en DSCP 0 dans les deux sens !
C'est donc bien le forfait prioritaire 180 Go 5G+ le problème :(

Je vais creuser l'analyse en regardant quel trafic exactement est tagué en DSCP 18 (ou autre) par le réseau Orange

Merci pour ton idée :)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: Max le 02 octobre 2025 à 01:17:40
Je viens de faire quelques tests encore :

Le remarquage du trafic WireGuard en DSCP 18 ne se fait qu'à l'intérieur du RBCI, en effet, je viens de monter un tunnel vers un serveur OVH que je possède et je n'ai pas de problème de débit et tout arrive bien en DSCP 0 avec mon forfait prioritaire.
Donc j'ai concentré mes tests à l'intérieur du RBCI, j'ai pris deux IPs de probes Atlas dans l'AS3215 et j'ai fait des ping et ping6, et bingo, en IPv4 je reçois les réponses taguées en DSCP 18 aussi ! Et en IPv6 les réponses arrivent taguées en DSCP 40 (CS5)

Si je me mets en partage de connexion sur ma SIM Sosh 150 Go 5G, les réponses aux ping et ping6 vers les mêmes IPs sont en DSCP 0 !
Si je me mets en Wi-Fi sur ma Livebox 7, les réponses aux ping et ping6 vers les mêmes IPs sont également en DSCP 0

Si quelqu'un d'autre qui possède le même forfait Orange 180 Go 5G+ peut faire des tests de son côté pour valider la thèse ça serait cool :)
À noter aussi que si je désactive la 5G SA dans les paramètres de l'iPhone ça ne change rien, je reçois du DSCP 18/40 malgré tout... c'est vraiment la priorité le problème.

Et ce weekend je pense pouvoir tester avec un forfait Orange 5G+ mais non prioritaire (option SA activée dans l'espace client) mais je pense vraiment que c'est la priorité le problème.

Les IPs des sondes Atlas utilisées pour mes tests sont 92.135.37.151 et 2a01:cb19:9219:9000:c23f:d5ff:fe63:aa1

En espérant que quelqu'un chez Orange (@levieuxatorange ? :) ) veuille bien prendre ce problème à cœur, sinon je vais être obligé de changer de forfait pour un forfait classique sans priorité, mais j'ai pas envie :(
Merci !
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 02 octobre 2025 à 08:38:17
Citation de: Max le 02 octobre 2025 à 01:17:40
Je viens de faire quelques tests encore :

Le remarquage du trafic WireGuard en DSCP 18 ne se fait qu'à l'intérieur du RBCI, en effet, je viens de monter un tunnel vers un serveur OVH que je possède et je n'ai pas de problème de débit et tout arrive bien en DSCP 0 avec mon forfait prioritaire.
Donc j'ai concentré mes tests à l'intérieur du RBCI, j'ai pris deux IPs de probes Atlas dans l'AS3215 et j'ai fait des ping et ping6, et bingo, en IPv4 je reçois les réponses taguées en DSCP 18 aussi ! Et en IPv6 les réponses arrivent taguées en DSCP 40 (CS5)

Si je me mets en partage de connexion sur ma SIM Sosh 150 Go 5G, les réponses aux ping et ping6 vers les mêmes IPs sont en DSCP 0 !
Si je me mets en Wi-Fi sur ma Livebox 7, les réponses aux ping et ping6 vers les mêmes IPs sont également en DSCP 0

Si quelqu'un d'autre qui possède le même forfait Orange 180 Go 5G+ peut faire des tests de son côté pour valider la thèse ça serait cool :)
À noter aussi que si je désactive la 5G SA dans les paramètres de l'iPhone ça ne change rien, je reçois du DSCP 18/40 malgré tout... c'est vraiment la priorité le problème.

Et ce weekend je pense pouvoir tester avec un forfait Orange 5G+ mais non prioritaire (option SA activée dans l'espace client) mais je pense vraiment que c'est la priorité le problème.

Les IPs des sondes Atlas utilisées pour mes tests sont 92.135.37.151 et 2a01:cb19:9219:9000:c23f:d5ff:fe63:aa1

En espérant que quelqu'un chez Orange (@levieuxatorange ? :) ) veuille bien prendre ce problème à cœur, sinon je vais être obligé de changer de forfait pour un forfait classique sans priorité, mais j'ai pas envie :(
Merci !

Merci pour les tests, cela correspond comme résultat à ce que je pensais obtenir de ceux que j'allais faire.

L'alerte usage est en cours de remonté. Par contre dans les méandres de la boutique il faut que je trouve un market qui s'inquiète réellement de ce point ..

Mon estimation perso est que ce type d'usage va se rependre, même si cela représente 5% de notre population, cela sera plutôt les pro et gros consommateurs, j'ai donc une chance de faire entendre le message ..

Et sinon il est normal que en sortant du RBCI tout soit retagué en DSCP 0 . La CoS est une histoire "locale" à chaque opérateur, et par defaut, hors accord bien spécifique, tout est retagué à DCSP 0 à l'interco.

LeVieux

Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 02 octobre 2025 à 08:40:55
Citation de: vivien le 01 octobre 2025 à 21:00:00
En FTTH, c'est presque inutile et certains opérateurs ne priorisent pas la voix de la box sur leur propre réseau.
En phase avec le "presque".
Sauf si on rajoute la contrainte numéro d'urgence et où on veut pas que les voisins qui pompent des "films de vacances" à 10Gb/s puissent perturber les acheminements des appels d'urgence.

C'est de la parano d'opérateur (il faut tomber sur la personne qui appelle les num d'urgence sur un même arbre PON/XGSPON qu'un téléchargeur fou) mais avec la fin du cuivre, c'est un truc à prendre en compte.

LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 02 octobre 2025 à 09:20:50
Par contre si la communauté peux remonter à WireGuard que c'est "pas classe" de se déguiser en AF41 pour établir le tunnel ou au moins laisser le choix de ne PAS le faire, cela serait bien.
Cela sera plus générique comme réponse

On a des experts open source ici qui pourraient prendre cela ?

LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 02 octobre 2025 à 10:26:55
Il faut également remonter la demande à OpenSSH, non ?
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 02 octobre 2025 à 10:31:15
Citation de: vivien le 02 octobre 2025 à 10:26:55
Il faut également remonter la demande à OpenSSH, non ?
Oui ! effectivement, bien vu !
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: Max le 02 octobre 2025 à 10:39:50
J'ai fait encore d'autres tests ce matin :

Sur un Samsung Galaxy S24+ avec le forfait Orange 180 Go 5G+ (prioritaire, et ce n'est pas mon forfait à moi, c'est une autre SIM) j'ai exactement le même problème, le réseau d'Orange tag les paquets WireGuard et les ping en DSCP 18 (AF21) ainsi que les ping6 en DSCP 40 (CS5) vers des destinations au sein du RBCI (dans le sens réseau > smartphone).
J'ai aussi essayé en forçant l'APN en IPv4 et c'est le même problème...

Et j'ai testé avec une SIM Parnasse Orange 5G qui est en COS6 (priorité 4G/5G NSA) mais qui n'est pas sur le cœur de réseau 5G SA et tout est bien en DSCP 0 malgré la priorité...

Merci
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 02 octobre 2025 à 10:54:41
Après, je me demande si le plus efficace n'est pas de passer par les experts Linux chez Orange.

J'ai franchement été bluffé par le niveau de maîtrise des experts Linux Orange pour détecter puis faire corriger des sujets très complexes. Ils ont la capacité de proposer un code qui résout le bug et le faire remonter directement à la bonne personne en charge du code en question et que ce code soit déployé massivement.

Je pense que peu d'opérateur au niveau mondial ont ce niveau d'expertise en interne.

Citation de: vivien le 16 avril 2021 à 22:32:18
Chaque trois semaines, des centaines de correctifs dans le noyau Linux sont distribués, ils corrigent quoi ?

Il n'y a pas que des failles de sécurité qui sont corrigées. Il y a aussi des bugs qui peuvent vous impacter.

Je vais m'attarder sur un exemple précis de régression qui entraînait des période(s) de 200 millisecondes où le transfert réseau est interrompu, entraînant une baisse de débit moyen pouvant aller jusqu’à 10%, pour les connexions TCP impactées par cette violation de la RFC793 (https://tools.ietf.org/html/rfc793). Les RFC sont des documents décrivant les aspects et spécifications techniques d'Internet. Celle-ci date de 1981 et décrit le standard TCP (Transmission Control Protocol) que nous utilisons systématiquement sur Internet, au-dessus d'IPv4 ou d'IPv6. L'alternative possible à TCP est UDP.

Ce bug qui impactait tous les serveurs équipés d'un Linux récent a été découvert et corrigé par... Orange France.
J'ai vraiment été admiratif du travail des équipes d'Orange, qui consiste, quand il y a un bug, à ne pas se limiter à trouver un contournent, mais à chercher l'origine du bug dans le code et proposer un correctif au mainteneur du code en question, pour que le monde entier profite du correctif.

Concrètement pour Ubuntu, le 1er décembre 2020, le noyau 5.4.0-56-generic #62-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 était déployé pour succéder au noyau 5.4.0-54-generic.

Le noyau 5.4.0-55-generic qui intègre plus de 1300 correctifs de bug n'a pas été publié, car la CVE-2020-4788 classée "medium" est arrivée pendant sa phase de validation de non régression. Le 5.4.0-56-generic intègre le 5.4.0-55-generic et rajoute la correction de la CVE-2020-4788.

Dans la liste des 1300 correctifs, il y a tcp: fix receive window update in tcp_add_backlog(), le bug trouvé et corrigé par Orange. On va voir ce qui se cache derrière, les impacts et pourquoi ce type de bug est complexe à trouver.

La régression, découverte par Orange en octobre 2020, était dans le fichier tcp_ipv4.c:tcp_add_backlog(). Non seulement cela pouvait dégrader les performances réseau dans certaines circonstances mais c'était également la source d'un bug dans netfilter, un pare-feu intégré au sein du noyau Linux. Le patch (bugfix) proposé par Orange a été backporté dans la branche stable du noyau Linux et intégré par les différentes distributions plus ou moins rapidement. Pour Ubuntu, il a été poussé à tous le 1er décembre 2020 avec des centaines d'autres correctifs, dont une faille de sécurité, c'est donc proposé comme une mise à jour de sécurité.

Voici quelques diapositives, publiées avec l'accord d'Orange, qui explique la problématique technique :

(https://lafibre.info/testdebit/ubuntu/202009_orange_regression_linux_tcp_receive_window_update_1.png)

(https://lafibre.info/testdebit/ubuntu/202009_orange_regression_linux_tcp_receive_window_update_2.png)
Citation de: vivien le 16 avril 2021 à 22:36:21
Détail technique du problème rencontré :

L’algorithme TCP a dans sa structure deux octets pour indiquer la taille de la fenêtre demandée, c'est-à-dire le nombre d'octets que le récepteur souhaite recevoir sans accusé de réception. Un émetteur n’a strictement pas le droit d’émettre un paquet excédant la RWIN indiquée par le récepteur, comme l’explique la RFC793 (https://tools.ietf.org/html/rfc793).

Dans certains cas spécifiques, quand plusieurs paramètres sont réunis, notamment quand le client a une RWIN en diminution forte, jusqu’à devenir nulle nous observons une violation flagrante de la RFC par le serveur qui va envoyer 10ko de payload excédant la RWIN. La diminution de la RWIN est un mécanisme minoritaire, mais fréquent, qui a plus de chances de se déclencher lorsque le débit client est fort, car en situation de débit plus faible, les mécanismes de contrôle de congestion côté serveur prennent le dessus.

Les 10 ko de données envoyés en violation de la RFC793 sont peu, mais suffisant pour placer les piles TCP client et serveur dans un état non souhaité / non prévu :
  • Le client va droper ces paquets supplémentaires, faute de mémoire pour les stocker.
  • Par la suite le client n’émet que des acquittements TCP avec une RWIN qui continue de diminuer pour devenir nulle.
  • Lorsque de la place est de nouveau disponible dans sa mémoire, le client envoie un acquittement au serveur, avec une RWIN non nulle, mais inférieure aux 10ko excédentaires.
  • Le serveur reçoit cet acquittement TCP lui indiquant qu’il peut envoyer des paquets... qu’il a déjà envoyé. Le serveur ne fait donc rien.
  • Émetteurs et récepteur restent en attente pendant environ 200ms, avant un TLP (Tail Loss Probe) envoyée par le serveur qui fait redémarrer les échanges.

Impacts sur les performances :

Cette problématique peut se produire plusieurs fois dans une même connexion TCP utilisée pour un transfert d’un fichier de 50 Mo.

Les conséquences sont une ou des période(s) de 200 millisecondes où le transfert est interrompu, entraînant une baisse de débit moyen pouvant aller jusqu’à 10%, pour les connexions TCP impactées par cette régression.

Tous les opérateurs sont potentiellement affectés cette violation de la RFC793, en IPv4 comme en IPv6. Cette baisse de débit moyen de 10% concerne uniquement des tests réalisés dans de très bonnes conditions radio.

(https://lafibre.info/testdebit/ubuntu/202009_orange_regression_linux_tcp_receive_window_update_3.png)

(https://lafibre.info/testdebit/ubuntu/202009_orange_regression_linux_tcp_receive_window_update_4.png)

(https://lafibre.info/testdebit/ubuntu/202009_orange_regression_linux_tcp_receive_window_update_5.png)

Précision, ces diapositives ont été crées avant que le bug dans le code Linux soit identifié.

Le correctif, intitulé tcp: fix receive window update in tcp_add_backlog() est présent dans les changelog du noyau diffusé le 1er décembre 2020 :
- Changelog du noyau Linux 5.4.0-56 du 1er décembre 2020 (https://lafibre.info/testdebit/ubuntu/202012_orange_fix_regression_linux_tcp_receive_window_update_kernel_ubuntu_5.4.txt)
- Changelog du noyau Linux 5.8.0-31 du 1er décembre 2020 (https://lafibre.info/testdebit/ubuntu/202012_orange_fix_regression_linux_tcp_receive_window_update_kernel_ubuntu_5.8.txt)

On peut remercier Orange pour le travail.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 02 octobre 2025 à 10:58:56
Citation de: vivien le 02 octobre 2025 à 10:54:41
Après, je me demande si le plus efficace n'est pas de passer par les experts Linux chez Orange.

Je vais faire regarder cela aussi par l'interne, bonne suggestion. Va falloir que je trouve les bons canaux ...
LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 02 octobre 2025 à 11:01:05
Citation de: Max le 02 octobre 2025 à 10:39:50
J'ai fait encore d'autres tests ce matin :

Merci pour ces tests (j'aurais jamais eu accès à autant de SIM sur autant d'offre différentes comme cela de mon coté :) !

L'alerte est lancée, on regarde comment adresser le problème par le bon bout ...

LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: kgersen le 02 octobre 2025 à 12:10:52
si qqun pouvait tester avec Tailscale voir si y'a le probleme aussi (c'est du wireguard en dessous mais pas le client officiel).
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: kgersen le 02 octobre 2025 à 12:35:21
Citation de: levieuxatorange le 02 octobre 2025 à 09:20:50
Par contre si la communauté peux remonter à WireGuard que c'est "pas classe" de se déguiser en AF41 pour établir le tunnel ou au moins laisser le choix de ne PAS le faire, cela serait bien.

Je suis de l'avis inverse, ce n'est "pas classe" de classifier tout le trafic à partir des premiers paquets ou la présence d'un seul paquet AF41. Ca devrait être stateless et "par paquet". Mais d'accord qu'on puisse le désactiver coté Wireguard.

Il faudrait voir ce que disent les RFCs en détails, mais je serais prêt a parier que la notion de flux (ou meme de TCP ou UDP vu que ca peut être un autre proto L4) n'a rien a  faire la. Ca devrait être du stateless L3 pur (IP pur) voir du L2 (avec mapping CoS), paquet par paquet.

Et quelle(s) raison(s) aurait eu Orange de classifier tout un flux sur quelques paquets ? je ne vois pas. On ne peut abuser du truc car au contraire on se retrouve pénaliser.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: daleksek le 02 octobre 2025 à 13:00:13
Citation de: kgersen le 02 octobre 2025 à 12:10:52
si qqun pouvait tester avec Tailscale voir si y'a le probleme aussi (c'est du wireguard en dessous mais pas le client officiel).
Avec Tailscale, je n'étais plus bridé en débit par rapport à une connexion directe en SSH
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 02 octobre 2025 à 13:00:59
Citation de: kgersen le 02 octobre 2025 à 12:35:21
Je suis de l'avis inverse, ce n'est "pas classe" de classifier tout le trafic à partir des premiers paquets ou la présence d'un seul paquet AF41. Ca devrait être stateless et "par paquet". Mais d'accord qu'on puisse le désactiver coté Wireguard.

Il faudrait voir ce que disent les RFCs en détails, mais je serais prêt a parier que la notion de flux (ou meme de TCP ou UDP vu que ca peut être un autre proto L4) n'a rien a  faire la. Ca devrait être du stateless L3 pur (IP pur) voir du L2 (avec mapping CoS), paquet par paquet.

Et quelle(s) raison(s) aurait eu Orange de classifier tout un flux sur quelques paquets ? je ne vois pas. On ne peut abuser du truc car au contraire on se retrouve pénaliser.
La il faudra laisser les experts en discuter, là vu la question ils vont de toutes les manières devoir s'y pencher en profondeur.

Ce qui n'est pas "classe" dans l'absolu c'est de mettre cela en place sans option de garder le comportement précédent, voir de figer la classe a ce que l'utilisateur décide / a besoin.
On pourrait même avoir des FW qui interdisent le passage de Pkt de ce type avec une QoS différente de celle attendu. Trouver une QoS "Flux Real Time VIDEO" sur un paquet d'établissement de VPN, cela peut être vu comme une violation de règle de sécu.


Et si effectivement, ce que tu indiques (cela doit être vu stateless avec une évolution possible de la classe utilisé au long de la vie du flux) de toutes les manière cela va devoir se regarder en profondeur sur beaucoup d'éléments du réseau pour prendre cela en compte dans les architectures à venir

en tout cas, le sujet est pris en compte et cela sera vu sous tous les angles, celui là aussi

LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: bigboo le 02 octobre 2025 à 13:54:03
Citation de: unipo le 30 septembre 2025 à 18:14:36
Retour de l'on côté,
À peu de chose près même setup que tvvmongeek.
Lien wireguard , les clients derrière livebox 5 ont un débit montant bloqué à 5Mbit/s.
Forcer la CoS sur un router (OpenWRT) permet de corriger le tir. Chose bien moins commode sur les différents clients windows/iOS/Android.

Salut,
est-ce que tu peux détailler s'il-te-plait comment tu as fait pour forcer le CoS à 0 sur ton routeur OpenWRT?
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 02 octobre 2025 à 15:34:48
@kgersen ta question sur le maintient d'un même DSCP tout au long du flux mérite une conversation à part entière et qui n'est pas liée que à Orange.

J'ai ouvert un thread la dessus
https://lafibre.info/tcpip/dscp-de-la-conservation-dun-unique-dscp-sur-la-vie-dun-flux/

Pour échange avec discussion autour des RFC et des pratiques (bonnes ou mauvaises) vue sur le réseau en 2025 et de ce que l'on imagine qui pourrait être une vision pour le futur.

Ce thread visera à être très technique, pour ceux qui se sentent de venir participer.

LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 03 octobre 2025 à 09:55:44
Bonjour

L'alerte est remonté et a été reçu a bon niveau.
J'ai eu l'info que le travail commence :
- pour faire une action court terme pour rétablir le rendu correcte du service dans ce cas d'usage
- long terme pour réfléchir à comment offrir le meilleur réseau possible en prenant en compte l'état de l'art DSCP 2025. Celui là va piquer un peu plus je pense vu nos discutions.

LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: fifi200 le 04 octobre 2025 à 14:17:54
Citation de: levieuxatorange le 02 octobre 2025 à 10:31:15
Oui ! effectivement, bien vu !

Le client OpenSSH a un parametre IPQoS qui permet de choisir le DSCP suivant que la connection est interactive ou pas.

Le défaut sur 10.0p1 de debian 13 / proxmox 9 est :

Code: [Sélectionner]
# sshd -T|grep -i qos
ipqos lowdelay throughput
La doc : https://man7.org/linux/man-pages/man5/ssh_config.5.html (https://man7.org/linux/man-pages/man5/ssh_config.5.html)

Code: [Sélectionner]
IPQoS   Specifies the IPv4 type-of-service or DSCP class for
               connections.  Accepted values are af11, af12, af13, af21,
               af22, af23, af31, af32, af33, af41, af42, af43, cs0, cs1,
               cs2, cs3, cs4, cs5, cs6, cs7, ef, le, lowdelay,
               throughput, reliability, a numeric value, or none to use
               the operating system default.  This option may take one or
               two arguments, separated by whitespace.  If one argument
               is specified, it is used as the packet class
               unconditionally.  If two values are specified, the first
               is automatically selected for interactive sessions and the
               second for non-interactive sessions.  The default is af21
               (Low-Latency Data) for interactive sessions and cs1 (Lower
               Effort) for non-interactive sessions.
Un point a mentionner aux dev wireguard pour leur demander d'ajouter une option :)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: lpouzenc le 04 octobre 2025 à 18:42:44
Bonjour,
Pour ce qui est de la question de bugreport côté wireguard, je veux bien m'en charger, mais j'ai une première nouvelle : ça se passe via une mailing list, et en consultant son archive, il y a déjà eu plusieurs discussions avec le mot clé DSCP là bas, la recherche gogole suivante les met en évidence :

https://www.google.com/search?q=site:lists.zx2c4.com/pipermail/wireguard DSCP

Et la question est peut être déjà restée indécise entre 2019 et 2021 :
https://lists.zx2c4.com/pipermail/wireguard/2019-March/004046.html
https://lists.zx2c4.com/pipermail/wireguard/2021-July/006853.html

Et côté wireguard linux, on ne peut pas dire qu'ils font rien à propos de DSCP (plusieurs pages de commits rien que sur 2025 et 2024) :
https://git.zx2c4.com/wireguard-linux/log/?qt=grep&q=DSCP

J'hésite à pousser un message dans ma mailing list en candide et en ayant pas encore trop compris quels sont les différents aspect sécurité vs performance qu'ils ont déjà balayé mais je crains que ça soit maladroit. Je vais essayer de lire un peu + chez eux d'abord. Un gars mentionne des "design decisions" de l'équipe de wireguard et je ne sais pas où les lire pour l'instant.

Amicalement,
Ludovic
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: lpouzenc le 04 octobre 2025 à 18:48:58
Re-bonjour,

Plutôt un message pour @LeVieuxAtOrange :

Est-ce qu'il y a pu y avoir des avancées IPv6 pour :
- les tags DSCP qui ne sont pas forcés à CS0 au niveau des interco autre opérateurs -> Orange
- les tags DSCP apparemment forcés en autre que CS0 au niveau de (certaines?) livebox

Je force mes backups en ssh en IPv4 pour l'instant, pour ne pas tomber dans le cas 5mbit/s max en IPv6, qui se produit même si je mets tout bien en CS0 aux deux bouts (client ssh local, avant une livebox 6 et serveur ssh distant).

Merci,
Ludo
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: kgersen le 04 octobre 2025 à 19:16:53
Citation de: lpouzenc le 04 octobre 2025 à 18:42:44
Bonjour,
Pour ce qui est de la question de bugreport côté wireguard,

bugreport de quoi ? y'a pas de bug a mon sens.

et y'a l'autre sujet sujet pour discuter pour savoir si c'est un bug ou pas.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: renaud07 le 04 octobre 2025 à 21:31:42
J'ai fait quelques tests de mon côté et il semble que seule la réponse au handshake soit tag AF41, donc une règle côté serveur et c'est terminé, non ?
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: lpouzenc le 04 octobre 2025 à 21:47:12
Citation de: kgersen le 04 octobre 2025 à 19:16:53
bugreport de quoi ? y'a pas de bug a mon sens.

et y'a l'autre sujet sujet pour discuter pour savoir si c'est un bug ou pas.

Je propose ça en réaction à la lecture du message #80 de ce thread, j'ai tenté ma maigre contribution dans l'autre thread plutôt à propos de SSH. BurReport pour au moins voir d'avoir une option - si elle n'existe vraiment pas - pour pouvoir configurer une autre comportement sur le DSCP que celui par défaut dans wireguard.

Idéalement, s'il n'y avait jamais de bwlimit du tout dans le réseau que je serai plus heureux, on est dans la même équipe je pense :)

Ludo
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: lpouzenc le 04 octobre 2025 à 22:27:03
Citation de: renaud07 le 04 octobre 2025 à 21:31:42
J'ai fait quelques tests de mon côté et il semble que seule la réponse au handshake soit tag AF41, donc une règle côté serveur et c'est terminé, non ?

Merci pour la capture. Pour le cas essayé, une seule règle serveur devrait suffire effectivement. A priori, tous les packets du handshake sont taggé AF41, dans les deux sens par les implémentations de wireguard, j'imagine que tu captures à un endroit à après une première altération qui nous arrange (ptet une livebox en v4 qui a bien remis à 0 des choses ?) mais je n'ai pas tout le contexte.

Dans le cas IPv6 / livebox 6 / Sosh Fibre chez moi, il y a un petit empilement de problèmes actuels qui font que non, même une règle côté serveur, ça ne suffit pas. Comme pour ssh dans mon cas, mettre IPQoS CS0 aux deux bouts ne suffit pas.

En tout cas, en ayant rattrapé 3 semaines de messages de ce thread d'un seul coup, je crois comprendre qu'il faudrait que tous les clients Wireguard aient une option pour CS0 les paquets handshake pour couvrir toutes les combinaisons qui amènent à 5mbit/s en l'état actuel (les cas 5G, les cas box qui reset pas le DSCP, les cas interco inter-opérateur qui reset pas les DSCP...).

En allant dire bonjour sur https://web.libera.chat/#wireguard j'ai un gars qui m'a pointé le paragraphe qui affirme qu'ils mettent AF41 sur tous les packets de handshake et pourquoi : https://www.wireguard.com/protocol/#diffserv-considerations

Et la réaction du gars à propos de "voice" et 5mbit/s est : I'm assuming they classify AF41 as "voice"?

Ce qui en allant brièvement relire sur wikipedia en étant fatigué ce soir, est effectivement un peu fort de café vu d'un dev d'un protocole / outils de VPN probablement :

Application PHB DSCP RFC
Network Control CS6 48 RFC 2474[3]
VoIP Telephony EF 46 RFC 3246[4]
Call Signaling CS5 40 RFC 2474[3]
Multimedia Conferencing AF41 34 RFC 2597[5]
Real-Time Interactive/TelePresence CS4 32 RFC 2474[3]
Multimedia Streaming AF31 26 RFC 2597[5]
Broadcast Video CS3 24 RFC 2474[3]
Low-Latency/transactional data AF21 18 RFC 2597[5]
Operations/administrations/management CS2 16 RFC 2474[3]
High-Troughput/Bulk Data AF11 10 RFC 2597[5]
Best Effort DF 0 RFC 2474[3]
Low-Profit/Scavenger Data CS1 8 RFC 3662[6]

Ludo
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: renaud07 le 04 octobre 2025 à 23:53:50
J'ai fait ma capture depuis un client windows et derrière ma connexion qui a un openWRT et pas de Livebox (idem côté serveur, pas de LB), donc les paquets ne sont normalement pas modifiés.

Autre capture depuis mon smartphone, là aussi j'ai CS0 puis AF41 en réponse. Serait-ce uniquement le client Linux qui tag tout ? (j'ai pas encore vérifié)

EDIT : C'est effectivement le client Linux qui tag aussi l’initiation.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: lpouzenc le 05 octobre 2025 à 07:50:12
Merci pour les captures !

Dans le dépôt wireguard-windows, le mot clé DSCP n'apparait apparemment pas. Mais bon comme il y a plusieurs quasi-synonymes (differentiated services, TOS), il faudrait lire +.

Dans le dépot android, il est mentionné 2 cas de figure : l'app Wireguard essaiera d'utiliser l'implémentation kernel de wireguard si elle est dispo, sinon utiliser une implémentation user-space (qui ne modifie pas le DSCP, peut être même parce qu'elle ne le peut pas du tout via l'api fournie). Dans le premier cas, c'est la codebase linux qui est utilisée, donc elle va très probablement forcer AF41 au handshake... mais cette config n'est peut être pas très répandue aujourd'hui, je ne sais pas s'il existe des kernel android officiels qui embarquent wireguard / à partir de quelle version. https://git.zx2c4.com/wireguard-android/tree/README.md#n5
L'intégration est expliquée ici : https://git.zx2c4.com/android_kernel_wireguard/about/

Je pourrai essayer un tel avec GrapheneOS dans quelques temps, j'imagine qu'ils ont wireguard dans le kernel.

Plus j'avance, plus je me dit que même si une option était ajoutée demain pour choisir le DSCP, on l'aurai de dispo sur tous les cas de figure plausiblement impactés dans plusieurs années (rien que par le jet lag entre le moment où du code non-security-patch est poussé dans les nouveaux kernels et leur utilisation dans une partie majoritaire du parc de smartphone ou de distro linux serveurs).
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: unipo le 05 octobre 2025 à 12:41:24
@lpouzenc
Juste pour info, sur GrapheneOS wireguard ne fonctionne qu'en userspace (https://nitter.net/GrapheneOS/status/1656015374037524488).
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: lpouzenc le 06 octobre 2025 à 08:35:31
Citation de: unipo le 05 octobre 2025 à 12:41:24
@lpouzenc
Juste pour info, sur GrapheneOS wireguard ne fonctionne qu'en userspace (https://nitter.net/GrapheneOS/status/1656015374037524488).

Merci ! Ca fait une branche en moins sur l'arbre des questions. Il n'y aura vraisemblablement pas de pb de DSCP AF41 avec wireguard sur GrapheneOS.

Est-ce qu'il y a des gens ici qui ont eu la limite à 5mbit/s et qui ne sont pas dans le cas où au moins un des peer wireguard concerné est un serveur linux, ou bien avec un serveur linux mais où le DSCP a été forcé avec une commande "tc" ou une règle iptables/nftables ?

Je vais probablement essayer tailscale/headscale et construire une commande pour forcer le DSCP sous linux pour wireguard aujourd'hui.

Ludovic
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: lpouzenc le 06 octobre 2025 à 10:41:22
Pour contourner le problème de limitation à 5mbit/s dans le cas d'une connexion wireguard entre un serveur linux et un client qui ne tagge pas les paquets handshake (apparement : clients windows, au moins certains android), si on est admin du serveur linux et qu'il est relativement moderne et configuration de firewall préalable (ne pas mélanger avec du viel iptables).

root@my-linux-server:~# editor /etc/nftables.conf
(personnaliser les lignes define et les commandes mentionnées après selon le nom de l'interface réseau connectée à internet et la valeur ListenPort configurée dans votre config WireGuard).

Code: [Sélectionner]
#!/usr/sbin/nft -f
define if_internet = ens6
define port_wireguard = 5678
flush ruleset
table inet filter {
        chain input { type filter hook input priority filter; policy accept; }
        chain forward { type filter hook forward priority filter; policy accept; }
        chain output {
                type filter hook output priority filter; policy accept;
                oifname $if_internet udp sport $port_wireguard ip dscp set cs0
        }
}

Puis activer une première fois et vérifier avec :

root@my-vps:~# /etc/nftables.conf
root@my-vps:~# nft list ruleset

Cette commande list ruleset devrait montrer les règles présente et actives au niveau du kernel. Elle devrait notamment contenir la ligne qui se termine par ip dscp set cs0.

Pour observer le traffic modifié, éteindre le tunnel depuis le client puis, sur le serveur :

root@my-vps:~# tcpdump -nvc10 -i ens6 udp port 5678
tcpdump: listening on ens6, link-type EN10MB (Ethernet), snapshot length 262144 bytes

# Allumer le client tant que cette commande bloque le terminal

08:27:28.330676 IP (tos 0x0, ttl 44, id 26194, offset 0, flags [none], proto UDP (17), length 176)
    X.Y.Z.W.5678 > A.B.C.D.5678: UDP, length 148
08:27:28.331160 IP (tos 0x0, ttl 64, id 58739, offset 0, flags [none], proto UDP (17), length 120)
    A.B.C.D.5678 > X.Y.Z.W.5678: UDP, length 92
08:27:28.370997 IP (tos 0x0, ttl 44, id 26202, offset 0, flags [none], proto UDP (17), length 60)
    X.Y.Z.W.5678 > A.B.C.D.5678: UDP, length 32
^C

Vérifier que les valeurs "tos" sont bien à 0 sur les 3 premiers paquets (=handshake, normalement tous les suivants étaient déjà à 0). Terminer la capture de paquets par Ctrl-C.

Pour les distributions de type Debian et normalement beaucoup d'autres, ce fichier là sera automatiquement chargé par systemd au démarrage du système si le paquet nftables est installé.
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 06 octobre 2025 à 13:57:40
@vivien tu pourrais me préciser exactement l'abonnement que tu as sur ta 5G Home  avec le Flybox 2 ?
C'est du 5G+ Home ou du 5G "normal" HOME ?

C'est pour les Lab chez Orange pour reproduire tous ces cas et choisir la bonne modif à faire au bon endroit (pour le court terme)

Reste la longue discution sur l'autre Thread de " c'est quoi au global la bonne cible"

LeVieux

Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: vivien le 06 octobre 2025 à 14:34:30
Matériellement, j'ai une Flybox 2-5G
Modèle : 5G19-01W-A
J'ai laissé la configuration par défaut, sauf pour le SSID WiFi.

L'abonnement, c'est de la 5G "normal" NSA, car j'ai souscrit en juillet 2024 (Le passage en 5G SA nécessite une résiliation et une re-souscription, ce que je n'ai pas fait, concrètement si dans l'interface, je force le mode "5G SA uniquement", je perds le réseau).

La SIM a été changée après un incident en mai 2025 sur mon antenne (déviation en temps de la synchro PTP sur la zone générant un brouillage de l’UL) - quand le support voit un pb, il change la SIM et ensuite, il change la box (moi je n'ai pas été faire le changement des box, mais des voisins si). À aucun moment, ils se disent que plusieurs clients sur la même zone appellent pour le même pb, cela ne doit pas être une SIM défectueuse, mais l'antenne.

(https://lafibre.info/images/ipv6/202507_flyxbox_version_firmware.webp)
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: kgersen le 06 octobre 2025 à 17:04:34
Citation de: lpouzenc le 04 octobre 2025 à 22:27:03

Et la réaction du gars à propos de "voice" et 5mbit/s est : I'm assuming they classify AF41 as "voice"?

Ce qui en allant brièvement relire sur wikipedia en étant fatigué ce soir, est effectivement un peu fort de café vu d'un dev d'un protocole / outils de VPN probablement :

Application PHB DSCP RFC
Network Control CS6 48 RFC 2474[3]
VoIP Telephony EF 46 RFC 3246[4]
Call Signaling CS5 40 RFC 2474[3]
Multimedia Conferencing AF41 34 RFC 2597[5]
Real-Time Interactive/TelePresence CS4 32 RFC 2474[3]
Multimedia Streaming AF31 26 RFC 2597[5]
Broadcast Video CS3 24 RFC 2474[3]
Low-Latency/transactional data AF21 18 RFC 2597[5]
Operations/administrations/management CS2 16 RFC 2474[3]
High-Troughput/Bulk Data AF11 10 RFC 2597[5]
Best Effort DF 0 RFC 2474[3]
Low-Profit/Scavenger Data CS1 8 RFC 3662[6]

Ludo

A ma connaissance, AF41 n'est explicitement "normalisé" pour la voix/conf. Cisco et d'autres présentent des tableaux avec ca (que wikipédia a repris) mais dans la RFC rien n'est imposé.
Rien n’empêche de s'en servir pour wireguard. L'avantage d'AF41 "CS4 low drop" donc la plus prio, low drop des 4 classes utilisables pour du trafic applicatif. En gros ce qui a le plus de change de ne pas se perdre sans être 'prio systeme ou vitale".
AF41 a été utilisé pour du gaming aussi (meme si de nos jours ca ne sert plus trop hors LAN/WAN privé).
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 07 octobre 2025 à 08:36:19
Citation de: kgersen le 06 octobre 2025 à 17:04:34
A ma connaissance, AF41 n'est explicitement "normalisé" pour la voix/conf. Cisco et d'autres présentent des tableaux avec ca (que wikipédia a repris) mais dans la RFC rien n'est imposé.
Rien n’empêche de s'en servir pour wireguard. L'avantage d'AF41 "CS4 low drop" donc la plus prio, low drop des 4 classes utilisables pour du trafic applicatif. En gros ce qui a le plus de change de ne pas se perdre sans être 'prio systeme ou vitale".
AF41 a été utilisé pour du gaming aussi (meme si de nos jours ca ne sert plus trop hors LAN/WAN privé).
Coté Orange j'ai le sentiment que l'on a la même lecture : AF41 (et CS4 en général) c'est de la Voix / VISIO
Mais je suis d'accord avec toi, la relecture des RFC mélange les deux notions :
- AF41 classe 'générique" utilisable pour plein d'application. Et sans obligation pour une application de rester sur une et unique QoS
- mais la voix collant très bien à AF4x, c'est utilisé plein de fois en exemple. Et a été repris de plus en plus dans le "langage courant" comme étant la QoS des flux voix.

LeVieux
Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: levieuxatorange le 10 octobre 2025 à 09:54:47
Citation de: lpouzenc le 04 octobre 2025 à 18:48:58
Re-bonjour,

Plutôt un message pour @LeVieuxAtOrange :

Est-ce qu'il y a pu y avoir des avancées IPv6 pour :
- les tags DSCP qui ne sont pas forcés à CS0 au niveau des interco autre opérateurs -> Orange
- les tags DSCP apparemment forcés en autre que CS0 au niveau de (certaines?) livebox

Je force mes backups en ssh en IPv4 pour l'instant, pour ne pas tomber dans le cas 5mbit/s max en IPv6, qui se produit même si je mets tout bien en CS0 aux deux bouts (client ssh local, avant une livebox 6 et serveur ssh distant).

Merci,
Ludo
Bonjour
@lpouzenc
Comme j'ai les experts directement sur le sujet, peux tu me mettre en MP les IPv4 et v6 qui te posent soucis.
Entre la variété d'équipement et de version, un point de conf a pu être mis de travers.
Mais la cible est bien remarquage à BE / DSCP0 pour tous les flux entrant IPv4 Ipv6 depuis l'extérieur de l'AS3215.

On va tracer les chemins et revérifier

LeVieux



Titre: Orange: Débit limité à 5 Mb/s avec les flux DSCP 2 ou certains VPN
Posté par: Sylvain92 le 16 octobre 2025 à 16:57:27
Pour le MPLS (BVPN) Orange, les classes sont les suivantes:

(https://i.postimg.cc/mhYBdy3B/COS-BVPN-Orange.png) (https://postimg.cc/mhYBdy3B)