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