Auteur Sujet: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau) (Lu 130480 fois)

vivien · « **Réponse #192 le:** 20 juin 2016 à 10:02:15 »

ca ne marche pas sur ftp://1.testdebit.info ?

underground78 · « **Réponse #193 le:** 20 juin 2016 à 10:24:21 »

Je ne sais plus si c'était sur lafibre.info mais je suis sûr d'avoir déjà discuté de ça avec un abonné Free ZMD et il avait fini par réussir à faire fonctionner FTP en configurant son client.

Archange · « **Réponse #194 le:** 20 juin 2016 à 10:24:54 »

[/quote]

Citation de: vivien le 20 juin 2016 à 10:02:15

ca ne marche pas sur ftp://1.testdebit.info ?

Pour moi cette question ? Si oui, je ne suis pas chez moi avant fin de journée.

AbP · « **Réponse #195 le:** 20 juin 2016 à 16:44:36 »

Citation de: underground78 le 20 juin 2016 à 10:24:21

Je ne sais plus si c'était sur lafibre.info mais je suis sûr d'avoir déjà discuté de ça avec un abonné Free ZMD et il avait fini par réussir à faire fonctionner FTP en configurant son client.

NewsGroup proxad.free.services.pagesperso
utilisateur david le 11/03/2016 à 22:51:32 sur le Plessis-Trévise :

"Mon adresse IP est bien partagée avec 3 autres utilisateurs, mais nous avons chacun une plage de ports attribués différente.
La mienne: Ports 0 à 16383
Filezilla permet de paramétrer une plage de port en mode "actif" donc j'ai inséré ma plage de ports
(en fait 1024 - 16383 car Filezilla ne prend pas moins).
En me connectant maintenant en mode "actif" je récupère donc mes accès FTP."

A tester.

Archange · « **Réponse #196 le:** 20 juin 2016 à 16:53:20 »

Je teste ce soir...
Cependant, à partir du moment ou le client à la plage "0/16383" il ne devrait rencontrer de pb

underground78 · « **Réponse #197 le:** 20 juin 2016 à 17:12:06 »

Le problème avec le FTP sortant (en mode client donc) concerne potentiellement tous les utilisateurs avec une IP partagée (en fait ça serait même plutôt les utilisateurs qui ont une plage élevée qui ont le moins de chance d'être affectés).

« **Réponse #198 le:** 21 juin 2016 à 19:14:15 »

Je ne comprends pas de quel problème tu veux parler!

didjee34 · « **Réponse #199 le:** 10 juillet 2016 à 17:23:34 »

Hello à tous,

Pour info: j'ai basculé en mode Full IPv4 (IP dédiée).

J'ai pris un peu de temps aujourd'hui pour ressortir mon ERLite 3 du placard ! J'en ai profité pour le passer de la version 1.7.0 à la toute dernière 1.8.5.

Alors, il y a effectivement du mieux, genre du beaucoup beaucoup mieux !

J'ai effectivement plus aucun de soucis de MTU sur l'interface WAN en DHCP (en IPv4) avec la Freebox Mini 4K en mode bridge (bug bien fixé du coup). Que cela soit en MTU 1472/1480/1500/9000 ça passe et j'ai tout le temps l'accessibilité au réseau.

Par contre, j'ai un gros soucis de performance (pourtant l'Offloading est activé pour le forwarding / GRE / PPPoe / VLAN en IPv4 au niveau de l'ERLite).

Si je fais un gros IPerf3 vers ping.online.net en mode Routeur, je fais du 680 Mbit/s en Download, et dans les 250 Mbit/s en Upload.

Si je passe en mode bridge, et que je refais le test IPerf à partir du même serveur, je tourne systématiquement à 220 Mbit/s en Download et 250 Mbit/s en Upload.

Il y a un soucis niveau performance au niveau de l'ERLite, ou alors du mode bridge de la freebox mini 4K. Pourtant l'ERLite ne sature pas niveau charge CPU ... etrange !

A noter que la télévision fonctionne parfaitement en mode bridge, le boitier TV est synchro en Wifi 5Ghz sur mon Point d'accès wifi, 0 configuration de VLAN avec la Freebox mini 4K.

Je vais creuser le sujet pour la baisse de performance en mode bridge ... je ne sais pas trop pourquoi encore. Peut être justement parce que je ne précise aucun VLAN spécifique ... je ne sais pas.

Il faut que je teste avec un poste fixe avec interface reseau gigabit pour éliminer la piste du soucis au niveau de l'ERLite.

Il faudrait aussi que je teste en mode DHCP IPv6 pour le WAN... mais ça me semble pénible, et j'ai pas trop le temps pour le moment.

Wait&See

Didier

Hugues · « **Réponse #200 le:** 10 juillet 2016 à 18:51:41 »

Tu as testé le test de débit local de la freebox ? Ça sera routé via l'ERL.

Et tu peux faire un Wget depuis la CLI de l'ERL aussi ;-)

AbP · « **Réponse #201 le:** 11 juillet 2016 à 11:28:56 »

Un test sous Windows qui fonctionne habituellement bien :
https://www.speedtest.net/fr/index.php

un autre :
https://testdebit.info/

Sans oublier les tests de neutralité présentés ici :
https://lafibre.info/tester-son-debit/test-neutralite/

ce qui donne par exemple sous Linux :
wget -O /dev/null ftp://3-ipv6.testdebit.info/1000Mo/1000Mo.iso

Buzzer · « **Réponse #202 le:** 15 décembre 2016 à 15:44:05 »

Bonjour,

Seriez vous au courant de pb de performances sur l'infrastructure zmd de Free ? Car dans notre entreprise, nous utilisons Cisco anyconnect pour l'accès distant, qui permet en plus du https (tcp 443) de faire du dtls (udp 443). Le problème c'est que l'Infra zmd semble induire des perte de paquet, et la négociation du mtu dans le tunnel en dtls echoue 99% du temps. Mais pas en https car tcp gère les pertes de paquets.

Nous avons trouver 2 parades :
- bloquer le udp 443 pour les personnes ayant des soucis (autre que free)
- demander une ipv4 full stack (free uniquement)

Effectivement, passer en full stack supprime les pertes de paquets.
Pour l'instant le pb s'est présenté chez 10 freenautes et à été résolu avec une ip full stack. Vu le déploiement de Free je pense que le nombre de personnes concernées va augmenter.

Pour info, le dtls est deconfigurable, mais non souhaitable, car plus performant pour la TOIP. Le mtu dans le tunnel est paramétré à 1300 avec un overhead de 96 maxi. La négociation devrait donc passer des le premier paquet, mais à cause des pertes, ça echoue.

Donc 2 choses :
- Pb de perf sur l'Infra d'ip partagée ?
- différence d'Infra entre full stack et ip partagée ?

Merci des éventuelles infos.

alain_p · « **Réponse #203 le:** 15 décembre 2016 à 21:25:56 »

Bonjour Buzzer,

Merci pour la remontée des témoignages. Dans quelle région êtes-vous ? C'est peut-être un problème régional, ou même lié à un NRO/switch Free ?

Pour le MTU, Rani Assaf lui-même avait affirmé ici même qu'ils faisaient du jumbo frame, pour le tunnel IPv6 qui transporte l'IPv4, et donc que le MTU IPv4 était toujours de 1500 octets. Il y avait eu des problèmes au début des ZMDs et de la mise en place de cette techno 4rd, mais il avait été constaté ensuite que le MTU était bien en IPv4 de 1500. Il faudrait peut-être refaire des tests.

Pour l'IPv4 "full stack", ce serait une autre bonne raison de prendre l'option...

Sinon, ce qu'ont commencé à constater certains, c'est une baisse progressive des débits en ZMD, et cela peut venir effectivement de l'infrastructure. Si elle est surchargée, il peut y avoir des pertes de paquets.