La Fibre
Fournisseurs d'accès à Internet mobile et 5G/4G fixe => 5G/4G Orange / Sosh => 
5G Home Orange => 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.