La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Bouygues Telecom => 
Débit fibre Bouygues => Discussion démarrée par: luke7110 le 02 décembre 2024 à 14:17:24
-
Je suis chez Bytel depuis vendredi, j'ai fait quelques speedtests, le débit varie de 1,5Gb (à l'heure où je vous écris) à 3,5Gb testé dimanche. J'ai pas vu plus élevé pour l'instant.
C'est qques chose de normal ou faut-il s'alarmer ?
J'ai un switch 10Gb et si je fais un iperf3 sur mon NAS j'ai bien 9,5Gb en moyenne, donc pas de problème de carte.
Le speedtest a été fait avec un cable en direct depuis le pc sur la box.
La box montre les détails de connexion suivants :
(https://i.ibb.co/9255pkK/Screenshot-2024-12-02-141356.png) (https://imgbb.com/)
Non pas que ce delta me pose un problème, je me demande juste si c'est normal.
Merci !
-
Oui il faut faire des test en parallèle j'avais ce problème avec free.
En lançant 15 speed test différent serveur en ligne de commande j'avai systématiquement 8gb
Avec un 16/32 bit un 386 sx lol
Non.. 16/32 cœur bien sur 5950x
-
C'est quoi des speedtest serveur en ligne de commande ? J'ai testé avec des serveurs iperf mais j'arrive pas à un trouver un correct qui réponde et qui dépasse le gigabit ...
-
J'avais posté ça ya quelque page
J'ai fait un petit batch qui lance 30 speed test à la fois j'avais systématiquement 8gb avec free
Avec speedest navigateur non (avec un 5950x)
Le gigabit???ça sent limitation carte réseau ça. Chaise clavier lol
-
Non non j'ai bien 9,5Gb en testant iperf entre mon PC et mon NAS.
Tu te rappelles où tu l'as posté ce batch?
-
En ligne de commande, vous pouvez faire des commandes curl vers les serveurs de testdebit.info.
Sinon il y a nspeed de @kgersen.
Sources et exemples : https://github.com/nspeed-app/nspeed
Binaires : https://dl.nspeed.app/nspeed-client/latest/
Pour le 10Gbps, vous pouvez tester avec le serveur Appliwave 40Gbps : "nspeed from https://dl.nspeed.app/aw" (download, upload, download avec 4 connexions, upload avec 4 connexions), et au besoin reprendre les commandes et adapter.
-
Il y a plein de raisons qui peuvent expliquer un débit TCP mono-connexion WAN en dessous du débit attendu.
J'ai d'ailleurs fait un outil open-source dédié à cette problématique, qui permet de vérifier automatiquement pas mal de causes possibles: checkFtthFree (https://lafibre.info/1gb-free/checkftthfree-test-de-debit-tcp-mono-connexion-freeboxcubicbbr/) (exécutable Windows: checkFtthFree.exe (https://github.com/Yaribz/checkFtthFree/releases/latest/download/checkFtthFree.exe), script Perl pour autres systèmes: checkFtthFree.pl (https://github.com/Yaribz/checkFtthFree/releases/latest/download/checkFtthFree.pl))
Cet outil fonctionne sur n'importe quelle connexion, pas seulement chez Free. Il suffit d'ajouter le paramètre "-F" au moment de le lancer pour sauter le test local qui se fait normalement avec une Freebox (c'est l'équivalent du test que tu as déjà fait avec ton NAS de toutes façons). Si des problèmes sont détectés par l'outil, tu peux aussi ajouter le paramètre "-s" pour activer les suggestions automatiques.
-
Non non j'ai bien 9,5Gb en testant iperf entre mon PC et mon NAS.
Tu te rappelles où tu l'as posté ce batch?
bonjour ah merci a Viven d'avoir separe les sujets
oui je l'envoie ici a renomer en .bat bien sur
-
Il y a plein de raisons qui peuvent expliquer un débit TCP mono-connexion WAN en dessous du débit attendu.
J'ai d'ailleurs fait un outil open-source dédié à cette problématique, qui permet de vérifier automatiquement pas mal de causes possibles: checkFtthFree (https://lafibre.info/1gb-free/checkftthfree-test-de-debit-tcp-mono-connexion-freeboxcubicbbr/) (exécutable Windows: checkFtthFree.exe (https://github.com/Yaribz/checkFtthFree/releases/latest/download/checkFtthFree.exe), script Perl pour autres systèmes: checkFtthFree.pl (https://github.com/Yaribz/checkFtthFree/releases/latest/download/checkFtthFree.pl))
Cet outil fonctionne sur n'importe quelle connexion, pas seulement chez Free. Il suffit d'ajouter le paramètre "-F" au moment de le lancer pour sauter le test local qui se fait normalement avec une Freebox (c'est l'équivalent du test que tu as déjà fait avec ton NAS de toutes façons). Si des problèmes sont détectés par l'outil, tu peux aussi ajouter le paramètre "-s" pour activer les suggestions automatiques.
Merci ouno, je viens de tester l'outil et voici le retour :
===============================================================================
checkFtthFree
---------------
Programme de diagnostic de connexion FTTH Free
Ce programme analyse la configuration réseau du système et effectue différents
tests TCP (latence et débit mono-connexion) afin d'évaluer les performances de
la connexion FTTH et détecter d'éventuels dysfonctionnements.
Diverses options sont disponibles pour configurer ou désactiver certains tests,
voir --help (-h) pour plus d'information.
Avant de continuer, veuillez vérifier que rien d'autre ne consomme de la bande
passante sur le réseau (ordinateurs, Freebox player, télévision...), ni du CPU
sur le système de test (mises à jour automatiques, antivirus...).
===============================================================================
Appuyer sur Entrée pour continuer (ou Ctrl-C pour annuler)...
[checkFtthFree v0.24] Windows 11 Build 22631 (64-bit)
-------------------------- 2024-12-05 11:00:32 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Marvell AQtion 10Gbit Network Adapter
Adapter.DriverVersion: 3.1.10.0 (Marvell, 2024-04-23)
Adapter.EEE: Disabled
Adapter.FlowControl: Rx & Tx Enabled
Adapter.IPChecksumOffloadIPv4: Rx & Tx Enabled
Adapter.InterruptModeration: Enabled
Adapter.JumboPacket: Disabled
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV1IPv4: Enabled
Adapter.LsoV2: Enabled
Adapter.PcieLinkSpeed: 8.0 GT/s
Adapter.PcieLinkWidth: 2
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 512
Adapter.Rsc: Enabled
Adapter.SpeedDuplex: Auto Negotiation
Adapter.TCPUDPChecksumOffload: Rx & Tx Enabled
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Public
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 17.06 ms [gigue: 0.30 ms]
--> Débit: 632.85 Mo/s (5.06 Gbps) [fluctuation: 5.00%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 16.24 ms [gigue: 0.65 ms]
--> Débit: 373.30 Mo/s (2.99 Gbps) [fluctuation: 34.29%]
[!] La connexion aux serveurs de test semble affectée par de la perte de paquets
(ratio débit CUBIC/BBR: 58.99%)
-------------------------- 2024-12-05 11:01:02 +0100 --------------------------
Donc, visiblement j'arrive au moins à du 5Gb, là où speedtest s'arrête à 3.5Gb, mais l'outil me détecte de la perte de paquets. Qu'est-ce que ça peut suggérer ?
L'option -s me dit simplement de vérifier qu'il n'y a rien d'autre qui consomme la bande.
-
tres bonne chose ce test tcp le miens est bcp plus bourrin et moins informatif : le batch de plein de speed test en paralelle ca pourrait etre interessant le lancer aussi?
-
tres bonne chose ce test tcp le miens est bcp plus bourrin et moins informatif : le batch de plein de speed test en paralelle ca pourrait etre interessant le lancer aussi?
En effet c'est ce que je comptais faire.
Je l'ai lancé, le gestionnaire de tâches montrait une activité qui ne dépassait pas 3,2Gb environ, puis au bout d'une minute peut être tout s'est arrêté ... ça a fait tomber la connexion internet !
-
oula ... oui ca c'est signe surchauffe... mon truc il est bourrin lol c'est l'equivalent de prime95 ou cinebench23 niveau carte reseau pendant 10 min ca la teste a fond
avec ma carte asus ca plantait (10gb) et adaptateur aussi j'ai mis a jour les pilote et modifie le throttling, ca plantait a deconecter la carte reseau fallait je fasse activer.. apres ca reduisait la vitesse mais gardait la connection..
clairement thermique la
-
regarde avec nspeed en multi:
binaire: https://dl.nspeed.app/nspeed-client/latest/nspeed_windows_amd64_v1/nspeed.exe
.\nspeed.exe -cpu -color get -n 4 http://appliwave.testdebit.info/10G/10G.iso
Sauf changement chez bytel, le max possible est d'environ 7,5 Gbps.
-
Oui d'ailleurs me demandait le module sfp 8gbit permet l upload aussi ? À priori c'est symétrique le xgs pon d'où le s mais me demandait si yavais pas un bridage dans celui envoyé par Bouygues.
-
Oui d'ailleurs me demandait le module sfp 8gbit permet l upload aussi ? À priori c'est symétrique le xgs pon d'où le s mais me demandait si yavais pas un bridage dans celui envoyé par Bouygues.
Le bridage à 1Gbps en upload est côté OLT.
La BBox (le SFP étant juste une interface électrique <=> optique) émet à 10Gbps puisque c'est la norme XGS-PON, mais l'OLT ne l'autorisera à émettre que environ 1/8 du temps au maximum.
-
Ah parfait merci donc un jour ils peuvent le débrider facilement
-
Avec nspeed et le serveur indiqué ça ne donne pas grande chose ...
nspeed.exe -cpu -color get -n 4 http://appliwave.testdebit.info/10G/10G.iso
running jobs of '#0' (0)...
| c0| c1| c2| c3| c4| c5| c6| c7| c8| c9|c10|c11|c12|c13|c14|c15|c16|c17|c18|c19|c20|c21|c22|c23| jobs | threads|
| 4| 0| 1| 0| 0| 0| 0| 0| 13| 0| 0| 0| 14| 0| 0| 0| 0| 0| 1| 1| 0| 0| 0| 0| 4 | 16 |
| 15| 0| 0| 0| 0| 0| 2| 0| 11| 0| 0| 0| 2| 0| 0| 0| 0| 0| 2| 2| 0| 2| 0| 0| 4 | 16 |
| 3| 0| 2| 0| 0| 0| 2| 0| 6| 2| 0| 0| 2| 0| 0| 0| 2| 0| 0| 0| 0| 3| 0| 0| 4 | 16 |
| 9| 0| 0| 0| 0| 0| 0| 0| 18| 0| 0| 0| 2| 0| 0| 0| 0| 0| 0| 2| 2| 0| 0| 0| 4 | 16 |
| 8| 0| 0| 0| 0| 0| 0| 0| 8| 0| 2| 0| 3| 0| 0| 0| 3| 0| 2| 0| 0| 0| 0| 2| 4 | 16 |
| 6| 0| 2| 0| 0| 0| 0| 0| 9| 0| 0| 0| 5| 0| 0| 0| 0| 0| 2| 0| 0| 0| 0| 0| 4 | 16 |
| 6| 0| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 2| 0| 0| 0| 8| 5| 2| 3| 2| 9| 0| 2| 4 | 16 |
| 5| 0| 0| 0| 0| 0| 0| 0| 14| 0| 0| 0| 3| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 2| 4 | 10 |
batch #0:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 206.8 Mbps| 0 bps| 8.00| 206.8 MB| 0 B|4 x get http://appliwave.testdebit.info/10G/10G.iso (IPv4 - 26.13 ms - HTTP/1.1 - )
Avec l'outil checkFtthFree j'ai eu ça :
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 17.36 ms [gigue: 0.43 ms]
--> Débit: 566.12 Mo/s (4.53 Gbps) [fluctuation: 1.71%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 16.48 ms [gigue: 0.35 ms]
--> Débit: 262.14 Mo/s (2.10 Gbps) [fluctuation: 30.98%]
[!] La connexion aux serveurs de test semble affectée par de la perte de paquets
(ratio débit CUBIC/BBR: 46.30%)
Suggestion:
- vérifier que rien d'autre ne consomme de la bande passante
puis ça :
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 17.11 ms [gigue: 0.59 ms]
--> Débit: 333.94 Mo/s (2.67 Gbps) [fluctuation: 58.04%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 16.21 ms [gigue: 0.39 ms]
--> Débit: 677.49 Mo/s (5.42 Gbps) [fluctuation: 16.95%]
puis ça:
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 17.31 ms [gigue: 0.57 ms]
--> Débit: 525.89 Mo/s (4.21 Gbps) [fluctuation: 28.71%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 16.36 ms [gigue: 0.41 ms]
--> Débit: 496.44 Mo/s (3.97 Gbps) [fluctuation: 25.77%]
-
tres curieux pour nspeed, pourrais tu essayer avec cette version: https://dl.nspeed.app/nspeed-client/preview/nspeed_windows_amd64_v1/nspeed.exe
et
.\nspeed.exe -color -cpu get -n 4 http://scaleway.testdebit.info/10G/10G.iso
-
par contre c'est bien d'avoir separé le sujet pour le debit mais c'est un cas un peu particulier... pour le probleme de option debit+ ca touche bcp de monde, on pourrait renomer le titre et mettre ca avec? merci
-
tres curieux pour nspeed, pourrais tu essayer avec cette version: https://dl.nspeed.app/nspeed-client/preview/nspeed_windows_amd64_v1/nspeed.exe
et
.\nspeed.exe -color -cpu get -n 4 http://scaleway.testdebit.info/10G/10G.iso
Avec cette version ça marche effectivement mieux, j'ai ça :
nspeed-p.exe -color -cpu get -n 4 http://scaleway.testdebit.info/10G/10G.iso
running jobs of '#0' (0)...
| c0| c1| c2| c3| c4| c5| c6| c7| c8| c9|c10|c11|c12|c13|c14|c15|c16|c17|c18|c19|c20|c21|c22|c23| jobs | threads|
| 39| 0| 0| 0| 0| 2| 0| 0| 0| 13| 0| 0| 6| 0| 1| 0| 4| 9| 9| 9| 7| 6| 6| 12| 4 | 16 |
| 42| 0| 0| 0| 0| 2| 2| 0| 2| 2| 2| 0| 8| 0| 0| 0| 6| 10| 5| 8| 8| 6| 8| 6| 4 | 16 |
| 33| 0| 2| 0| 0| 0| 0| 0| 6| 0| 0| 0| 5| 0| 0| 0| 0| 0| 0| 2| 0| 0| 2| 0| 4 | 16 |
| 42| 0| 0| 0| 0| 0| 0| 0| 5| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 2| 0| 0| 4 | 16 |
| 28| 0| 0| 0| 0| 0| 0| 0| 8| 3| 0| 0| 3| 0| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 4 | 16 |
| 27| 0| 0| 0| 0| 0| 0| 0| 8| 0| 0| 0| 5| 0| 0| 0| 0| 0| 2| 2| 2| 0| 0| 0| 4 | 16 |
| 25| 0| 2| 0| 0| 0| 5| 0| 8| 2| 0| 0| 6| 0| 5| 0| 5| 0| 5| 11| 8| 14| 0| 5| 4 | 16 |
| 34| 0| 0| 0| 2| 0| 5| 0| 11| 0| 0| 0| 2| 0| 3| 0| 0| 0| 0| 2| 0| 2| 0| 0| 4 | 4 |
batch #0:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 2.8 Gbps| 0 bps| 8.00| 2.8 GB| 0 B|4 x get http://scaleway.testdebit.info/10G/10G.iso (IPv4 - 21.511 ms - HTTP/1.1 - )
nspeed-p.exe -color -cpu get -n 4 http://scaleway.testdebit.info/10G/10G.iso
running jobs of '#0' (0)...
| c0| c1| c2| c3| c4| c5| c6| c7| c8| c9|c10|c11|c12|c13|c14|c15|c16|c17|c18|c19|c20|c21|c22|c23| jobs | threads|
| 26| 0| 1| 0| 0| 0| 0| 0| 13| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 1| 0| 0| 4 | 16 |
| 50| 0| 0| 0| 0| 0| 2| 0| 23| 0| 0| 0| 2| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 4 | 16 |
| 34| 0| 0| 0| 0| 0| 0| 0| 5| 0| 0| 0| 3| 0| 2| 0| 0| 2| 0| 0| 0| 2| 0| 0| 4 | 16 |
| 31| 0| 0| 0| 0| 0| 0| 0| 15| 0| 0| 0| 6| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 2| 4 | 16 |
| 26| 0| 0| 0| 0| 0| 3| 0| 6| 0| 0| 0| 8| 0| 0| 0| 0| 0| 2| 0| 3| 0| 0| 0| 4 | 16 |
| 32| 0| 0| 0| 0| 0| 2| 0| 3| 0| 2| 0| 0| 0| 0| 0| 0| 0| 2| 0| 0| 0| 0| 0| 4 | 16 |
| 42| 0| 0| 0| 0| 0| 0| 0| 9| 0| 0| 0| 2| 0| 0| 0| 0| 0| 6| 2| 3| 0| 0| 2| 4 | 16 |
| 14| 0| 0| 0| 0| 0| 0| 0| 11| 0| 0| 0| 2| 0| 0| 0| 3| 2| 6| 5| 3| 13| 0| 0| 4 | 4 |
batch #0:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 2.8 Gbps| 0 bps| 8.00| 2.8 GB| 0 B|4 x get http://scaleway.testdebit.info/10G/10G.iso (IPv4 - 20.371 ms - HTTP/1.1 - )
Mais si je teste juste après avec checkFtthFree j'ai quand même plus :
[checkFtthFree v0.24] Windows 11 Build 22631 (64-bit)
-------------------------- 2024-12-05 14:45:09 +0100 --------------------------
Configuration réseau du système:
Adapter.Driver: Marvell AQtion 10Gbit Network Adapter
Adapter.DriverVersion: 3.1.10.0 (Marvell, 2024-04-23)
Adapter.EEE: Disabled
Adapter.FlowControl: Rx & Tx Enabled
Adapter.IPChecksumOffloadIPv4: Rx & Tx Enabled
Adapter.InterruptModeration: Enabled
Adapter.JumboPacket: Disabled
Adapter.LinkSpeed: 10 Gbps
Adapter.LsoV1IPv4: Enabled
Adapter.LsoV2: Enabled
Adapter.PcieLinkSpeed: 8.0 GT/s
Adapter.PcieLinkWidth: 2
Adapter.PhysicalMediaType: 802.3
Adapter.ReceiveBuffers: 512
Adapter.Rsc: Enabled
Adapter.SpeedDuplex: Auto Negotiation
Adapter.TCPUDPChecksumOffload: Rx & Tx Enabled
Adapter.TransmitBuffers: 2048
NetProfile.NetworkCategory: Public
Tcp.AutoTuningLevelLocal: Normal
Tcp.CongestionProvider: CUBIC
Tcp.EcnCapability: Disabled
Tcp.ScalingHeuristics: Disabled
Tcp.Timestamps: Allowed
=> Latence TCP max pour une réception à 1 Gbps: 141 ms
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 17.11 ms [gigue: 0.43 ms]
--> Débit: 575.43 Mo/s (4.60 Gbps) [fluctuation: 1.24%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 16.94 ms [gigue: 0.38 ms]
--> Débit: 664.94 Mo/s (5.32 Gbps) [fluctuation: 6.14%]
-------------------------- 2024-12-05 14:45:38 +0100 --------------------------
Ca se base sur le même serveur pour le test ? Scaleway si je comprends bien ?
-
par contre c'est bien d'avoir separé le sujet pour le debit mais c'est un cas un peu particulier... pour le probleme de option debit+ ca touche bcp de monde, on pourrait renomer le titre et mettre ca avec? merci
Je suis désolé mais je n'avais pas vu qu'il y avait déjà un sujet et j'en ai fait un nouveau, ce n'est pas une séparation.
-
ah pardon j'ai cru c'etait vivien qui avait separé les 2 non c'est tres bien et ca permet peut etre a d'autre qui ont ce soucis de le corriger... mais vu ya un gros probleme avec l'option debit+ ah ben je vais l'ouvrir lol
-
Ca se base sur le même serveur pour le test ? Scaleway si je comprends bien ?
oui curieusement 4 flux depuis le meme serveur sont moins bons qu'un seul flux...
peut-etre un souci de lecture du cpu sur ton ordi ?
Tu peux vérifier avec:
.\nspeed.exe from https://dl.nspeed.app/scaleway
-
Ah oui, c'est exactement ça!
nspeed-p.exe from https://dl.nspeed.app/scaleway
reading commands from https://dl.nspeed.app/scaleway
running jobs of 'download mono' (0)...
running jobs of 'upload mono' (1)...
running jobs of 'download multi' (2)...
running jobs of 'upload multi' (3)...
batch download mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 5.4 Gbps| 0 bps| 8.00| 5.4 GB| 0 B|get http://scaleway.testdebit.info/10G/10G.iso (IPv4 - 19.839 ms - HTTP/1.1 - )
batch upload mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#1| 0 bps| 718.9 Mbps| 8.00| 0 B| 718.9 MB|post http://scaleway.testdebit.info/ul/ 10.7 GB (IPv4 - 17.390 ms - - )
batch download multi:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#2| 3.1 Gbps| 0 bps| 8.00| 3.1 GB| 0 B|4 x get http://scaleway.testdebit.info/10G/10G.iso (IPv4 - 20.704 ms - HTTP/1.1 - )
batch upload multi:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#3| 0 bps| 938.3 Mbps| 8.00| 0 B| 938.4 MB|4 x post http://scaleway.testdebit.info/ul/ 10.7 GB (IPv4 - 20.790 ms - - )
-
intéressant ton problème et rarement vu :)
je vois que t'es a Mougins dans le 06.
que donne
.\nspeed.exe from https://dl.nspeed.app/bytelpaca
-
Donc, visiblement j'arrive au moins à du 5Gb, là où speedtest s'arrête à 3.5Gb
Oui, plus de 5 Gbps en mono-connexion, ce qui est déjà pas mal en fait.
mais l'outil me détecte de la perte de paquets. Qu'est-ce que ça peut suggérer ?
Pour évaluer la présence de perte de paquets l'outil compare la vitesse de téléchargement en algorithme CUBIC avec celle en algorithme BBR. Mais dans ton cas de toutes façons les résultats semblent assez irréguliers donc ce n'est pas vraiment significatif.
Par contre le fait que tu aies des débits inférieurs en multi-connexions pose question. Et le fait que tu aies une coupure totale de la connexion lorsque tu lances beaucoup de téléchargements en parallèle aussi...
Il est possible que tu sois impacté par ce souci (https://www.bbox-mag.fr/forum/viewtopic.php?t=3988) (surchauffe du port RJ45 10 Gbps dans certaines conditions ?). La baisse du débit en multi-connexions pourrait n'être qu'un symptôme qui apparaitrait avant la coupure totale.
-
Oui sur a la fois sur l'adaptateur rj45 sfp sur mon mikrotik crs 305 et mon adaptateur usb ethernet et carte ethernet 10gb chaque fois le problème était la chaleur
-
intéressant ton problème et rarement vu :)
je vois que t'es a Mougins dans le 06.
que donne
.\nspeed.exe from https://dl.nspeed.app/bytelpaca
J'ai testé 3 fois et ça donne :
nspeed-p.exe from https://dl.nspeed.app/bytelpaca
reading commands from https://dl.nspeed.app/bytelpaca
running jobs of 'download mono' (0)...
running jobs of 'upload mono' (1)...
running jobs of 'download multi' (2)...
running jobs of 'upload multi' (3)...
batch download mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 5.0 Gbps| 0 bps| 8.00| 5.0 GB| 0 B|get http://aix-marseille.testdebit.info/10G/10G.iso (IPv4 - 7.53 ms - HTTP/1.1 - )
batch upload mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#1| 0 bps| 944.7 Mbps| 8.00| 0 B| 944.8 MB|post http://aix-marseille.testdebit.info/ul/ 10.7 GB (IPv4 - 6.530 ms - - )
batch download multi:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#2| 3.5 Gbps| 0 bps| 8.00| 3.5 GB| 0 B|3 x get http://aix-marseille.testdebit.info/10G/10G.iso (IPv4 - 18.287 ms - HTTP/1.1 - )
batch upload multi:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#3| 0 bps| 951.3 Mbps| 8.00| 0 B| 951.3 MB|4 x post http://aix-marseille.testdebit.info/ul/ 10.7 GB ( - -9223372036854.-775 ms - - )
nspeed-p.exe from https://dl.nspeed.app/bytelpaca
reading commands from https://dl.nspeed.app/bytelpaca
running jobs of 'download mono' (0)...
running jobs of 'upload mono' (1)...
running jobs of 'download multi' (2)...
running jobs of 'upload multi' (3)...
batch download mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 5.5 Gbps| 0 bps| 8.00| 5.5 GB| 0 B|get http://aix-marseille.testdebit.info/10G/10G.iso (IPv4 - 7.0 ms - HTTP/1.1 - )
batch upload mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#1| 0 bps| 945.0 Mbps| 8.00| 0 B| 945.0 MB|post http://aix-marseille.testdebit.info/ul/ 10.7 GB (IPv4 - 8.834 ms - - )
batch download multi:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#2| 4.5 Gbps| 0 bps| 8.00| 4.5 GB| 0 B|3 x get http://aix-marseille.testdebit.info/10G/10G.iso (IPv4 - 16.3 ms - HTTP/1.1 - )
batch upload multi:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#3| 0 bps| 950.2 Mbps| 8.00| 0 B| 950.4 MB|4 x post http://aix-marseille.testdebit.info/ul/ 10.7 GB (IPv4 - 10.263 ms - - )
nspeed-p.exe from https://dl.nspeed.app/bytelpaca
reading commands from https://dl.nspeed.app/bytelpaca
running jobs of 'download mono' (0)...
running jobs of 'upload mono' (1)...
running jobs of 'download multi' (2)...
running jobs of 'upload multi' (3)...
batch download mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 5.5 Gbps| 0 bps| 8.00| 5.5 GB| 0 B|get http://aix-marseille.testdebit.info/10G/10G.iso (IPv4 - 6.271 ms - HTTP/1.1 - )
batch upload mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#1| 0 bps| 946.2 Mbps| 8.00| 0 B| 946.3 MB|post http://aix-marseille.testdebit.info/ul/ 10.7 GB (IPv4 - 7.0 ms - - )
batch download multi:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#2| 4.3 Gbps| 0 bps| 8.00| 4.3 GB| 0 B|4 x get http://aix-marseille.testdebit.info/10G/10G.iso (IPv4 - 19.230 ms - HTTP/1.1 - )
batch upload multi:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#3| 0 bps| 944.8 Mbps| 8.00| 0 B| 944.9 MB|4 x post http://aix-marseille.testdebit.info/ul/ 10.7 GB ( - -9223372036854.-775 ms - - )
Et à titre de comparaison, sur la même plage horaire checkFtthFree :
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [BBR]
--> Latence: 17.45 ms [gigue: 0.45 ms]
--> Débit: 666.95 Mo/s (5.34 Gbps) [fluctuation: 21.44%]
Test TCP Internet (IPv4): téléchargement depuis l'AS 12876 (Scaleway) [CUBIC]
--> Latence: 16.47 ms [gigue: 0.31 ms]
--> Débit: 611.45 Mo/s (4.89 Gbps) [fluctuation: 15.96%]
-------------------------- 2024-12-05 17:40:00 +0100 --------------------------
-
Oui, plus de 5 Gbps en mono-connexion, ce qui est déjà pas mal en fait.
Pour évaluer la présence de perte de paquets l'outil compare la vitesse de téléchargement en algorithme CUBIC avec celle en algorithme BBR. Mais dans ton cas de toutes façons les résultats semblent assez irréguliers donc ce n'est pas vraiment significatif.
Par contre le fait que tu aies des débits inférieurs en multi-connexions pose question. Et le fait que tu aies une coupure totale de la connexion lorsque tu lances beaucoup de téléchargements en parallèle aussi...
Il est possible que tu sois impacté par ce souci (https://www.bbox-mag.fr/forum/viewtopic.php?t=3988) (surchauffe du port RJ45 10 Gbps dans certaines conditions ?). La baisse du débit en multi-connexions pourrait n'être qu'un symptôme qui apparaitrait avant la coupure totale.
Oui sur a la fois sur l'adaptateur rj45 sfp sur mon mikrotik crs 305 et mon adaptateur usb ethernet et carte ethernet 10gb chaque fois le problème était la chaleur
Alors, depuis les tests initiaux je suis passé sur mon infra définitive basée sur un routeur Ubiquiti Pro Max (avec IPS/IDS désactivé, donc pas de limitation de débit), je ne fais donc plus de tests en direct sur la bbox, mais bon comme le problème était présent dès le début, sans le routeur et en direct, je me suis dit que le problème était en amont de mon matériel.
Ceci dit, il est clair que les modules SFP+ 10GbE chauffent à mort... est-ce que le module est à prendre en compte dans l'équation ? Je referai les tests les plus problématiques en direct avec la box pour être sûr.
Ce qui est sûr c'est que quand internet a coupé lors des tests, j'avais erreur C1 sur la bbox, donc le problème était, à ce moment, à ce niveau là.
En revanche j'excluerai la carte réseau sur mon pc car je peux faire autant d'iperf que je veux entre mon NAS et mon PC et j'aurai toujours 9.5Gb sans aucun problème.
-
Oui sur mon pc avec mise à jour des drivers c'était bon mais j'ai des throttle des fois. Ca deconecte plus mais ralentit à 0 et reprend 10s après.
C'est les petit module aussi oui. Sur la notice mikrotik ils disent de séparer des adaptateur par un espace en laisser vide de port sfp..
Jai mis un petit ventilateur.
Ça serait intéressant brider la connection a 1gb sur le port 10 et voir ça donne quoi (côté carte réseau pc)
-
Je constate que tes tests checkftth et nspeed sont en IPv4...
Depuis peu les BBox font du MAP-T (transport d'IPv4 dans IPv6), il se peut qu'un bug/limitation de celle-ci entraine une souci de surchauffe par exemple quand y'a trop de débit a MAP-T.
Il serait pertinent de tester en IPv6.
-
Le MAP-T n'est pas limité aux clients en partage d'IPv4 ?
En revanche c'est étrange d'avoir les tests nspeed en IPv4, alors que les serveurs ont une IPv6 (qui devrait être préférée normalement).
-
Le MAP-T n'est pas limité aux clients en partage d'IPv4 ?
En revanche c'est étrange d'avoir les tests nspeed en IPv4, alors que les serveurs ont une IPv6 (qui devrait être préférée normalement).
Ne partez pas sur de fausses pistes, c'est ma faute je ne gère pas l'ipv6 sur mon routeur, je ne m'y suis pas encore mis 🫣
-
Je crois y'a un ensemble de chose je suis perdu à vos discussions
Des olt je crois selon que ce soit Bouygues ou pas dans une zone xp fibre ça plante ou pas
Des problèmes ipv4 seulement ipv6 ok
Des problèmes erreur c1 après utilisation intensive port 10gb
Des problèmes de reboot de box crash effacement log
-
Ne partez pas sur de fausses pistes, c'est ma faute je ne gère pas l'ipv6 sur mon routeur, je ne m'y suis pas encore mis 🫣
S'il y a du MAP-T, quand un client de la BBox (y compris ton routeur donc) fait de l'IPv4, la BBox traduit en fait en IPv6, jusqu'à un équipement Bouygues qui ressort en IPv4.
Normalement le meilleur moyen d'éviter ça est avoir des règles NAT configurées sur la BBox.
https://lafibre.info/bbox-les-news/bouygues-telecom-lance-une-offre-fibre-8-gbs-a-23-99-par-mois/msg1093580/#msg1093580
-
Du mal à comprendre ça. Quand j'ai eu ma bbox j'avais la même ip avant et après d'avoir ouvert les port
C'est vraiment en fonction de ça ya une source ?
Car dans l'espace client j'ai pas demander une ip full stack ou équivalent
Je veux dire que on peut très bien ne pas avoir ouvert des port et ne pas être en ip partagée
-
L'idée est de s'assurer qu'il ne soit pas en IP partagée, pour éliminer une éventuelle limitation liée à ça côté BBox ou côté réseau.
-
Oui tout à fait donc ouvrir les port est un bon moyen au cas où
Je crois que si ya pas l'option c'est que c'est bon
Moi j'ai un serveur Web chez moi donc premier truc j'ai fait c'est du nat dessus justement
-
Alors, depuis les tests initiaux je suis passé sur mon infra définitive basée sur un routeur Ubiquiti Pro Max (avec IPS/IDS désactivé, donc pas de limitation de débit), je ne fais donc plus de tests en direct sur la bbox, mais bon comme le problème était présent dès le début, sans le routeur et en direct, je me suis dit que le problème était en aval de mon matériel.
Oui, je parlais bien du port RJ45 10Gbps côté box. Mais en fait à y repenser ça ne doit pas être cela, car il y a au moins une personne qui a reproduit le problème en utilisant plusieurs ports RJ45 1 Gbps simultanément au lieu d'utiliser le port 10Gbps (ici (https://www.bbox-mag.fr/forum/viewtopic.php?p=25253#p25253)).
Et en plus en fait ce problème de coupure franche de l'IPv4 lors d'un gros trafic IPv4 prolongé semble plutôt être lié à un mécanisme de protection côté infra Bouygues qui a des valeurs seuils qui ne sont pas adaptées aux nouveaux débits (cf tests réalisés ici (https://lafibre.info/bbox-les-news/erreur-c1-sur-bbox-bouygues-offre-bbox-pure/msg1097820/#msg1097820) par noks et wobble).
-
Oui, je parlais bien du port RJ45 10Gbps côté box. Mais en fait à y repenser ça ne doit pas être cela, car il y a au moins une personne qui a reproduit le problème en utilisant plusieurs ports RJ45 1 Gbps simultanément au lieu d'utiliser le port 10Gbps (ici (https://www.bbox-mag.fr/forum/viewtopic.php?p=25253#p25253)).
Et en plus en fait ce problème de coupure franche de l'IPv4 lors d'un gros trafic IPv4 prolongé semble plutôt être lié à un mécanisme de protection côté infra Bouygues qui a des valeurs seuils qui ne sont pas adaptées aux nouveaux débits (cf tests réalisés ici (https://lafibre.info/bbox-les-news/erreur-c1-sur-bbox-bouygues-offre-bbox-pure/msg1097820/#msg1097820) par noks et wobble).
Un mécanisme de déni de service serait sauvage au point de déclencher une erreur C1 sur la box ?
-
j ai fait les test de bourrin quand javais mon module 2gb aucune coupure (30 speedtest simultanés) suivi de 500go de telechargement de jeux sur steam...
quand j'aurai la box avec le module a 8 je referai le test... mon fichier batch a fait crasher une box en 2min et ca faisait cracher ma carte 10gb avec les driver de base, et adaptateur 5gb usb aussi (avant modificiation parametre throttle si inferieur a n degré)
-
Un mécanisme de déni de service serait sauvage au point de déclencher une erreur C1 sur la box ?
Cette fameuse erreur C1 n'est pas une réelle erreur de la box, puisque le trafic vers l'IPv6 ou vers l'IPv4 de Bouygues fonctionne encore.
Donc la box fonctionne, je suppose que c'est juste qu'elle détecte que la connectivité IPv4 hors Bouygues n'est plus fonctionnelle.
-
ben ca depend y'avais je sais plus qui ou la box crachait et redemarait carrement... (et ca effacait les log)
-
Le MAP-T n'est pas limité aux clients en partage d'IPv4 ?
Oui, je confirme, MAP-T ne concerne que les clients avec une IPv4 partagée.
Si vous souhaitez en savoir plus, Bouygues Telecom explique bien son choix :
Adressage et transition IPv6 chez Bouygues Telecom
Le 7 décembre 2023, l’IDATE, l’Arcep et l’IPv6 Forum ont organisé, dans les locaux de l’Arcep, un atelier portant sur le développement et l’avancée de l’IPv6 en France. La pénurie d’adresses IPv4 fin 2019 appelle à accélérer la migration de tous les acteurs du net vers IPv6. Persister à entretenir le protocole IPv4 fait peser des risques sur le bon fonctionnement d’internet, notamment en termes d’accès aux services ou d’identification des adresses IP. La transition vers IPv6 est donc la seule solution pérenne pour qu’internet reste un espace d’innovation et de compétitivité, au bénéfice des utilisateurs.
Voici la présentation de Bouygues Telecom : Adressage et transition IPv6 chez Bouygues Telecom
https://www.youtube.com/watch?v=6RFsA1vsi70
Cette vidéo (29 minutes) est l'enregistrement de la présentation de Bouygues Telecom, réalisée par François Bouju.
Sommaire :
1/ Bouygues Telecom
2/ Déploiement IPv6
3/ Trafic IPv6
4/ Principes d’adressage
5/ Première étape : Dual-stack CGNAT 444
6/ Long terme : MAP-T
7/ MAP-T en exemple
8/ Points-clés
La présentation (10 pages) est disponible ci-dessous :
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/ipv6/202312_atelier_IPv6_08_Bouygues_Telecom_Transition_IPv6.webp) (https://lafibre.info/images/ipv6/202312_atelier_IPv6_08_Bouygues_Telecom_Transition_IPv6.pdf)
(https://lafibre.info/images/ipv6/202312_atelier_IPv6_08_Bouygues_Telecom_Transition_IPv6_1.webp)
-
oui merci Vivien mais quelque chose de pas clair pour moi :
quand on se connecte avec sa bbox sans ouvrir de port c'est different de Free n'est ce pas on est pas forcement avec le MAP-T?
car free il faut demander le full stack dans l'interface sinon par défaut on partage l'ip...
la quand on dit il faut ouvrir les ports pour ne pas avoir le MAP-T mais c'est dans les cas ou on est en partagé? parce que par exemple dans mon espace client j'avais pas d'option pour le full stack et mon ip publique n'a pas changé apres avoir ouvert les ports (j'ai un serveur web chez moi dual stack ipv4 ipv6 donc j'ai ouvert les ports 5 min apres avoir installé la box)
merci
-
oui merci Vivien mais quelque chose de pas clair pour moi :
quand on se connecte avec sa bbox sans ouvrir de port c'est different de Free n'est ce pas on est pas forcement avec le MAP-T?
car free il faut demander le full stack dans l'interface sinon par défaut on partage l'ip...
la quand on dit il faut ouvrir les ports pour ne pas avoir le MAP-T mais c'est dans les cas ou on est en partagé? parce que par exemple dans mon espace client j'avais pas d'option pour le full stack et mon ip publique n'a pas changé apres avoir ouvert les ports (j'ai un serveur web chez moi dual stack ipv4 ipv6 donc j'ai ouvert les ports 5 min apres avoir installé la box)
Free est par défaut en partage d'IPv4 (1/4 des ports), et même après avoir demandé une IP full stack l'abonné a tous les ports mais il passe toujours par le tunnel 4rd (encapsulation IPv4 dans IPv6).
Côté Bouygues, le partage d'IPv4 (en MAP-T, je ne sais pas s'il reste encore des abonnés en CGNAT, mais ils étaient peu nombreux) est à priori loin d'être généralisé, et pour ceux qui ont une IPv4 dédiée elle reste native.
-
Quelle est la manière plus simple de comprendre si on a une ip dédiée ou partagée ?
Ma bbox est en DMZ derrière mon routeur et toutes les redirections que je fais sur mon routeur fonctionnent.
-
Free est par défaut en partage d'IPv4 (1/4 des ports), et même après avoir demandé une IP full stack l'abonné a tous les ports mais il passe toujours par le tunnel 4rd (encapsulation IPv4 dans IPv6).
Côté Bouygues, le partage d'IPv4 (en MAP-T, je ne sais pas s'il reste encore des abonnés en CGNAT, mais ils étaient peu nombreux) est à priori loin d'être généralisé, et pour ceux qui ont une IPv4 dédiée elle reste native.
ah voila merci pour la precision c'est bien ce qu'il me semblait j'ai lu ici et la des choses erronnes, il faut ouvrir les ports pour pas etre en partagé etc alors que en fait ca ne concerne qu'une minorite..
-
Quelle est la manière plus simple de comprendre si on a une ip dédiée ou partagée ?
Ma bbox est en DMZ derrière mon routeur et toutes les redirections que je fais sur mon routeur fonctionnent.
a priori tout simplement tu a dans ce cas l'option : passer en ip non partagé ou equivalent
https://www.assistance.bouyguestelecom.fr/s/forum/question/0D5670000GVPZq4CQH/comment-repasser-en-ipv4-d%C3%A9di%C3%A9e-
-
En effet, ca fait penser à un souci dans l'implémentation MAP-T de la box ou du réseau, qui crash ou bug lorsqu'il y a trop de traffic.
Dans tous les cas, IP partagée ou dédiée, le traffic v4 passera par MAP-T. Pour l'opérateur, le but est d'avoir un réseau d'accès IPv6-only et de fournir un accès IPv4 as a service, par le biais de tunnels.
C'est le cas de Bouygues et de Free pour l'instant. Orange s'y prépare également, selon levieuxatorange.
-
ah voila merci pour la precision c'est bien ce qu'il me semblait j'ai lu ici et la des choses erronnes, il faut ouvrir les ports pour pas etre en partagé etc alors que en fait ca ne concerne qu'une minorite..
Je suppose que Bouygues migre des lots d'abonnés, mais (du moins actuellement) ils ne prennent que ceux n'ayant pas de port ouvert.
-
Dans tous les cas, IP partagée ou dédiée, le traffic v4 passera par MAP-T. Pour l'opérateur, le but est d'avoir un réseau d'accès IPv6-only et de fournir un accès IPv4 as a service, par le biais de tunnels.
C'est le cas de Bouygues et de Free pour l'instant. Orange s'y prépare également, selon levieuxatorange.
Vivien dit le contraire, donc ce n'est peut-être pas le cas actuellement (mais ça pourrait l'être plus tard).
Si le MAP-T devient vraiment obligatoire, ceux qui remplacent la BBox n'obtiendront plus d'IPv4 sur leur routeur, donc on le saura.
-
vu la pénurie (que certaines nient je comprend pas pourquoi) ca va pas etre le cas obligatoirement?
-
Vivien dit le contraire
J'aurais tendance à faire confiance aux infos de Vivien :-)
Je parlais plutôt de tendance à terme, Dans la présentation de Bouygues qu'il cite, on voit bien que le but à terme est de généraliser le MAP-T sur le réseau fixe.
Si le MAP-T devient vraiment obligatoire, ceux qui remplacent la BBox n'obtiendront plus d'IPv4 sur leur routeur, donc on le saura.
Oh, le réseau supportera peut-être encore DHCPv4 pour les clients en faisant la demande... on peut encore faire du PPPoE sur le VLAN 835 chez Orange, même si il ne doit pas rester beaucoup de boxes sur le réseau fibre en PPPoE.
Mais à terme, pour un opérateur, un réseau single stack v6-only est bien plus simple à gérer.
-
vu la pénurie (que certaines nient je comprend pas pourquoi) ca va pas etre le cas obligatoirement?
Une très large majorité des abonnés peuvent passer en IPv4 partagée sans s'en rendre compte, donc ce n'est pas le faible pourcentage d'utilisateurs demandant une IPv4 dédiée qui va changer grand chose pour la consommation d'IPv4.
En revanche, maintenir un réseau IPv4 natif pour une minorité ça a un coût, donc il n'est pas étonnant qu'à terme les opérateurs veuillent arrêter (Free ayant déjà commencé, ils doivent avoir une grande partie de leurs abonnés en 4rd maintenant).
-
Free ayant déjà commencé, ils doivent avoir une grande partie de leurs abonnés en 4rd maintenant
Tout leur parc fibre et la quasi totalité de l'ADSL dégroupé il me semble, non ?
Les lignes ADSL non dégroupées (si il y en a encore...) ne vont probablement pas être migrées.
-
Une très large majorité des abonnés peuvent passer en IPv4 partagée sans s'en rendre compte, donc ce n'est pas le faible pourcentage d'utilisateurs demandant une IPv4 dédiée qui va changer grand chose pour la consommation d'IPv4.
En revanche, maintenir un réseau IPv4 natif pour une minorité ça a un coût, donc il n'est pas étonnant qu'à terme les opérateurs veuillent arrêter (Free ayant déjà commencé, ils doivent avoir une grande partie de leurs abonnés en 4rd maintenant).
il y'a pénurie, point...
d'ailleurs les ipv4 sont de plus en plus chere et tu raisonne comme un homme du 20ieme siecle...
tu oublies completement les iot etc etc
-
On peut faire du MAP-T 1:1 (donc une IPv4 dédiée par client) et du 1:N en meme temps, il faut 2 "domaines" MAP-T. Un même relai peut gérer plusieurs domaines.
On ne sait pas trop ce que Bytel fait actuellement, la logique voudrait qu'il y ai qu'une seule architecture après la bbox donc que de l'IPv6 et tout le temps du MAP-T (comme Free et son MAP-E).
C'est plus simple pour le backbone, pour gérer le réseau a l'échelle du pays et pour la libération et réutilisation des IPv4 sur les relais MAP-T.
Mais ils sont surement en cours de migration donc il peut y avoir des soucis par endroit.
-
Vu ce qu'on observe ici : https://lafibre.info/bbox-les-news/erreur-c1-sur-bbox-bouygues-offre-bbox-pure/msg1097820/#msg1097820
Je ne serais pas surpris que Bytel fasse du MAP-T même sur ipv4 "full"
-
Pourquoi je peux faire du nat alors ?
-
Pourquoi je peux faire du nat alors ?
ca n'a rien a voir.
le MAP-T te fourni une IPv4 (dédiée ou partagée) sur la partie WAN de la bbox. Ensuite on peut faire du NAT pour la partager avec les appareils du LAN.
-
mais du coup ou est le partage?
si avec ca on a tous une ipv4 publique unique avec tout les ports?
-
De ce que je sais, c'est avec le CGNAT qu'on ne peut pas faire de NAT depuis l'extérieur vers le réseau local.
-
Oui mais ya bien un hic quelque part les adresse ipv4 publique sont limitées doit y avoir une contrainte quelque part
Avec ports partagés le nat ne marche pas si on a pas la bonne plage
8192 ports pour être précis. Et oui c'est suffisant même si ça réduit à 1 chance sur 8 d'avoir le "golden range" de ports < 8192. Contrairement à Free où c'est 1 chance sur 4.
Oui évidement quand je parle de Nat c'est le port de son choix...
-
vous parlez de "NAT entrant" la, on appelle cela de la redirection ou ouverture de port (port forwarding).
en 1-1 on peut avoir du port forwarding, en 1-8 c'est possible mais plus compliquer à faire. Il faut voir dans l'interface de la bbox ce qui est proposé quand on veut rediriger un port.
Car techniquement, en 1-8 le MAP-T découpe les ports (0 a 65535) en 16*8 tranches de 512 ports (appelé PSID) qu'il réparti en alternance fixe au 8 clients. Les 8 tranches basses (0-4096) sont en général réservées et pas utilisées. ca laisse 15 tranches de 512 ports par clients soit 7680 ports par clients (doc https://datatracker.ietf.org/doc/html/rfc7597#section-5.1 ).
ce n'est pas comme chez Free ou on a une seul tranche de ports contigus.
-
Ouïs voilà j'appelle pas ça faire du nat lol désolé
-
Ouïs voilà j'appelle pas ça faire du nat lol désolé
Je ne vois pas ou est le problème vu qu'on peut demander une IPv4 dédiée.
-
Ah tout à fait c'est pas le même problème tout à fait ce qui n'a rien à voir avec ce que j'ai dit
Le problème c'est dire on peut faire du nat avec cette technologie bien relire merci
-
Ah tout à fait c'est pas le même problème tout à fait ce qui n'a rien à voir avec ce que j'ai dit
Le problème c'est dire on peut faire du nat avec cette technologie bien relire merci
on ne comprend rien la (je ne suis pas le seul)... et on dévie du sujet initial.
Je t'invite éventuellement a ouvrir ton propre sujet sur le NAT ? parce que la déjà on va devoir bientôt nettoyer ce sujet.
-
Je constate que tes tests checkftth et nspeed sont en IPv4...
Depuis peu les BBox font du MAP-T (transport d'IPv4 dans IPv6), il se peut qu'un bug/limitation de celle-ci entraine une souci de surchauffe par exemple quand y'a trop de débit a MAP-T.
Il serait pertinent de tester en IPv6.
c'est qui qui a parlé de map-t donc de nat a la base?
donc on calme son enervement merci
tea culpa
apres on comprend rien comme j'ai dit ya plein de facteur