La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Actus fibre Free => Discussion démarrée par: didjee34 le 26 février 2016 à 14:32:14
-
Je crois que vous n'avez pas très bien suivi. Freewifi vérifierait le réseau d'où émane la demande de connexion, pour vérifier si c'est un réseau Free.
Le message d'erreur que voit toroyvaca est le suivant :
Donc rien à voir avec l'adresse IP du Freewifi lui-même.
Edit : Abel99 a même retrouvé une tâche ouverte sur le bugtracker :
http://dev.freebox.fr/bugs/task/19681
Oui c'est moi qui est ouvert ce ticket quand j'ai constaté le soucis sur la ligne de mes parents.
Depuis, j'ai migré également ma deuxieme ligne FTTH vers Free, et j'ai d'autres soucis qui vont je pense mériter des tickets chez eux.
1/ Un serveur Linux (Ubuntu 14.04 LTS ou Debian 8.3) au cul de la Freebox Mini 4K, impossible d'uploader (speedtest-cli) sans modifier la MTU de l'interface eth0 à 1472.
2/ Soucis en bypassant la freebox en mode bridge et en mettant à la place l'ERLite 3 (l'interface eth1 prend bien le DHCP et l'IP publique de la box) mais aucune resolution DNS possible (je pense que c'est le soucis de MTU 1472 qu'il faudrait que je reteste avec l'ERLite)
3/ Soucis pour maintenir un tunnel OpenVPN sous Debian / Ubuntu au cul de la Freebox. => Impossible en mode UDP (connexion établie mais 0 flux possible)
=> Possibilité de lancer le tunnel OpenVPN en mode TCP mais avec un débit limité pour le moment sans cryptage / auth à 16 Mo/s avec le serveur dédié (qui est en interface gigabit), le pire étant pour le moment qu'il est du coup impossible de maximiser la MTU du tun0/tap0 pour optimiser les performances.
Bref, pour le moment cette solution IP shared ne me convient pas vraiment... quid de la possibilité d'avoir une IP dédiée (via option payante ou pas) ? Quand ?
Didier
-
L'IP dédiée, Rani a dit que l'option serait gratuite, et que l'on pourrait même avoir plusieurs IP (option payante). Mais on attend toujours sa réponse sur la date de disponibilité de l'option...
Pour moi, en ZMD, c'est toujours en beta-test. Mais chez Free, on l'a souvent vu (freebox v6, 4K etc...), on peut être en beta-test et en même temps en étape de commercialisation. Il vaut mieux attendre que les soucis soient réglés avant de souscrire...
P.S : au fait, tu as quel range de ports ?
-
2/ Soucis en bypassant la freebox en mode bridge et en mettant à la place l'ERLite 3 (l'interface eth1 prend bien le DHCP et l'IP publique de la box) mais aucune resolution DNS possible (je pense que c'est le soucis de MTU 1472 qu'il faudrait que je reteste avec l'ERLite)
Moi je crois plutôt que comme l'ERL n'est pas au courant qu'il n'a pas droit à tous les ports, manque de chance le port source choisi pour les requêtes DNS (si tu utilises dnsmasq sur l'ERL) ne fait pas partie du range qui t'es attribué, et du coup la réponse "va chez ton voisin".
Personnellement j'ai du mal à voir comment le mode bridge peut fonctionner sans indiquer explicitement au routeur quelle plage de ports il peut utiliser.
-
Moi je crois plutôt que comme l'ERL n'est pas au courant qu'il n'a pas droit à tous les ports, manque de chance le port source choisi pour les requêtes DNS (si tu utilises dnsmasq sur l'ERL) ne fait pas partie du range qui t'es attribué, et du coup la réponse va chez ton voisin.
Personnellement j'ai du mal à voir comment le mode bridge peut fonctionner sans indiquer explicitement au routeur quelle plage de ports il peut utiliser.
Il se peut aussi qu'en mode bridge la V6 fasse aussi de la translation des ports clients.
Cette histoire de MTU est curieux par contre. Ce pourra indiquer qu'IPv4 est transporté par IPv6 contrairement a ce qu'on croyait ?
donc on a des tunnels sur IPv6 vers des gateway A+P qui en option pourront filer une IP complete sur demande ? c'est en fait du NAT64 stateless sans le coté 'dynamique' de suivre les ports ouverts ?
-
L'IP dédiée, Rani a dit que l'option serait gratuite, et que l'on pourrait même avoir plusieurs IP (option payante). Mais on attend toujours sa réponse sur la date de disponibilité de l'option...
Pour moi, en ZMD, c'est toujours en beta-test. Mais chez Free, on l'a souvent vu (freebox v6, 4K etc...), on peut être en beta-test et en même temps en étape de commercialisation. Il vaut mieux attendre que les soucis soient réglés avant de souscrire...
P.S : au fait, tu as quel range de ports ?
Pour info, sur ma ligne Free FTTH ZMD j'ai gagné à la loterie et j'ai le premier range [0 - 15000] (ou quelque chose comme ça). C'est sur cette ligne que j'ai fais les tests d'OpenVPN.
Je vais refaire joujou avec l'ERLite 3 ports et la freebox en mode bridge jusqu'à trouver le pourquoi du comment.
Et pour le CGNAT, je pense que c'est pour ça que le tunnel OpenVPN UDP ne passe pas aussi. (Il faut que je teste à partir d'un poste sous Windows)
Didier
-
Cette histoire de MTU est curieux par contre. Ce pourra indiquer qu'IPv4 est transporté par IPv6 contrairement a ce qu'on croyait ?
donc on a des tunnels sur IPv6 vers des gateway A+P qui en option pourront filer une IP complete sur demande ? c'est en fait du NAT64 stateless sans le coté 'dynamique' de suivre les ports ouverts ?
Il me semble au contraire que c'est ce que l'on disait depuis le début. D'après Vivien, et les tests de traceroute effectués, on ne peut pas tracer l'IP, car cela sort d'un tunnel IPv6 sur un routeur free à Paris (cf cyberjuls). Donc il y a peut-être effectivement un en-tête d'encapsulation à rajouter/déduire ?
-
Il me semble au contraire que c'est ce que l'on disait depuis le début. D'après Vivien, et les tests de traceroute effectués, on ne peut pas tracer l'IP, car cela sort d'un tunnel IPv6 sur un routeur free à Paris (cf cyberjuls). Donc il y a peut-être effectivement un en-tête d'encapsulation à rajouter/déduire ?
Ca n'était pas tranché en fait. si tu relis quelques pages à partir d'ici https://lafibre.info/free-la-fibre/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/msg283323/#msg283323.
On n'avait pas eu de confirmation du MTU en IPv4 car personne n'a fait de mesure (ou l'info m'a échappé). On en était resté a un A+P sans tunnel (curieux j'admet).
Cet nouvelle info de MTU semble indiqué des tunnels donc un NAT64, en fait un DS-Lite plutot (le NAT64 n'implique pas d'IPv4 coté client).
Donc Free ferait du DS-Lite avec NAT stateless pré-partagé une IP pour 4, les gateway DS-Lite étant en IDF (pour le moment).
C'est effectivement plus facile de proposer des IP full en option sur ce genre d'archi et ca permet le Pass-thru du VPN.
Ca clarifie nettement les choses. Ca veut dire aussi qu'en mode bridge la Freebox fait toujours le tunnel 4in6 donc on doit pouvoir mettre son propre routeur sans souci si on rêgle bien le MTU.
-
Je ne connaissais pas DS-Lite, et donc je me suis un peu renseigné. Cela semble tout à fait cela. Et donc la freebox n'aurait pas d'adresse IPv4 publique, c'est le routeur au bout du tunnel qui ferait la passerelle vers IPv4. L'article wikipedia en anglais me semble assez clair, et surtout le schéma qui l'accompagne :
Dual-Stack Lite technology does not involve allocating an IPV4 address to customer-premises equipment (CPE) for providing Internet access. It is described in RFC 6333. The CPE distributes private IPv4 addresses for the LAN clients, according to the networking requirement in the local area network. The CPE encapsulates IPv4 packets within IPv6 packets. The CPE uses its global IPv6 connection to deliver the packet to the ISP's Carrier-grade NAT (CGN), which has a global IPv4 address. The original IPv4 packet is recovered and NAT is performed upon the IPv4 packet and is routed to the public IPv4 Internet. The CGN uniquely identifies traffic flows by recording the CPE public IPv6 address, the private IPv4 address, and TCP or UDP port number as a session.[16]
https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite_.28DS-Lite.29
-
Je ne connaissais pas DS-Lite, et donc je me suis un peu renseigné. Cela semble tout à fait cela. Et donc la freebox n'aurait pas d'adresse IPv4 publique, c'est le routeur au bout du tunnel qui ferait la passerelle vers IPv4. L'article wikipedia en anglais me semble assez clair, et surtout le schéma qui l'accompagne :
https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite_.28DS-Lite.29
Sauf que la partie
The original IPv4 packet is recovered and NAT is performed upon the IPv4 packet and is routed to the public IPv4 Internet. The CGN uniquely identifies traffic flows by recording the CPE public IPv6 address, the private IPv4 address, and TCP or UDP port number as a session.
est fausse : pas de CGN, pas de "recording", même pas de NAT.
-
Un article du blog de Stéphane Bortzmeyer à propos de DS-Lite :
http://www.bortzmeyer.org/6333.html
P.S : Bortzmeyer était visionnaire en 2011, quand il a écrit ce billet :
Mais déplacer la fonction NAT depuis une machine située chez l'utilisateur vers le réseau du FAI crée des nouveaux défis. Par exemple, les adresses IPv4 publiques, qui n'étaient partagées qu'entre les membres d'une même famille ou les employés d'une même entreprise, vont désormais être partagées entre des clients du même FAI, clients qui ne se connaissent pas. Si la HADOPI voit 203.0.113.201 commettre un crime grave (par exemple partager des œuvres d'art), et qu'elle veut couper l'utilisateur de cette adresse, la probabilité de bavure devient bien plus élevée. Enregistrer les adresses IP ne suffit donc plus, il faut noter l'adresse IP et le port (RFC 6302) et que l'AFTR enregistre ses tables de correspondance (identité du tunnel, protocole, adresses et ports), comme précisé en section A.4.
-
Un article du blog de Stéphane Bortzmeyer à propos de DS-Lite :
http://www.bortzmeyer.org/6333.html
Voilà :
L'AFTR doit donc faire attention à empêcher les utilisateurs de monter une DoS (volontairement ou par accident) en s'attribuant tous les ports possibles. Par exemple, l'AFTR peut limiter le rythme d'allocation des ports, ou bien mettre une limite absolue au nombre de ports qu'un B4 peut s'allouer.
C'est inapplicable.
Donc Free ne fait pas vraiment du DS-Lite.
-
Pourquoi ce serait inapplicable ? Bortzmeyer cite même les solutions envisagées.
-
Donc en résumant (sans savoir si c'est du DS-Lite) en ZMD chez Free :
- IPv6 native
- IPv4 portée à travers IPv6 avec un mtu de 1472 octets
Du coup le mécanisme qui fait le partage des "ports" entre 4 freebox, ainsi que le tunnel, est déporté sur le NRO?, ou cela se situe directement dans l'infra de Free? (un peu à la manière d'un LNS)
-
Pourquoi ce serait inapplicable ? Bortzmeyer cite même les solutions envisagées.
Parce que ça n'existe pas chez Free, tout simplement :
L'AFTR doit donc faire attention à empêcher les utilisateurs de monter une DoS (volontairement ou par accident) en s'attribuant tous les ports possibles. Par exemple, l'AFTR peut limiter le rythme d'allocation des ports, ou bien mettre une limite absolue au nombre de ports qu'un B4 peut s'allouer.
Il n'y a pas de "rythme d'allocation des ports" parce qu'il n'y a pas d'allocation dynamique.
-
Ca n'était pas tranché en fait. si tu relis quelques pages à partir d'ici https://lafibre.info/free-la-fibre/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/msg283323/#msg283323.
On n'avait pas eu de confirmation du MTU en IPv4 car personne n'a fait de mesure (ou l'info m'a échappé). On en était resté a un A+P sans tunnel (curieux j'admet).
Cet nouvelle info de MTU semble indiqué des tunnels donc un NAT64, en fait un DS-Lite plutot (le NAT64 n'implique pas d'IPv4 coté client).
Donc Free ferait du DS-Lite avec NAT stateless pré-partagé une IP pour 4, les gateway DS-Lite étant en IDF (pour le moment).
C'est effectivement plus facile de proposer des IP full en option sur ce genre d'archi et ca permet le Pass-thru du VPN.
Ca clarifie nettement les choses. Ca veut dire aussi qu'en mode bridge la Freebox fait toujours le tunnel 4in6 donc on doit pouvoir mettre son propre routeur sans souci si on rêgle bien le MTU.
Alors je vous confirme après avoir écarté le doute sur le driver ethernet de mon contrôleur ethernet Nvidia MCP79 (Nvidia ION)... que sur un routeur ERLite le soucis de la MTU se confirme.
A partir du ERLite 3 :
MTU 1472
root@ubnt# ifconfig eth0 mtu 1472
root@ubnt# tracepath www.free.fr
1: 192.168.2.254 0.918ms pmtu 1472
1: 192.168.2.1 0.620ms
1: 192.168.2.1 0.652ms
2: 194.149.164.0 14.179ms
3: p11-crs16-1-be1003.intf.routers.proxad.net 17.461ms
4: p11-9k-1-be1000.intf.routers.proxad.net 15.077ms
5: bzn-9k-2-sys-be2001.intf.routers.proxad.net 14.872ms
6: no reply
7: no reply
8: no reply
MTU 1500
root@ubnt# ifconfig eth0 mtu 1500
root@ubnt# tracepath www.free.fr
1: 192.168.2.254 0.835ms pmtu 1500
1: 192.168.2.1 0.571ms
1: 192.168.2.1 0.544ms
2: no reply
3: no reply
4: no reply
5: no reply
Serveur debian 8 :
MTU 1500
root@vpnbox:~# tracepath www.free.fr
1?: [LOCALHOST] pmtu 1500
1: 192.168.2.1 0.330ms
1: 192.168.2.1 0.269ms
2: no reply
3: no reply
MTU 1472
root@vpnbox:~# ifconfig eth0 mtu 1472
root@vpnbox:~# tracepath www.free.fr
1?: [LOCALHOST] pmtu 1472
1: 192.168.2.1 0.322ms
1: 192.168.2.1 0.260ms
2: 194.149.164.0 13.980ms
3: p11-crs16-1-be1003.intf.routers.proxad.net 18.045ms
4: p11-9k-1-be1000.intf.routers.proxad.net 15.521ms
5: bzn-9k-2-sys-be2001.intf.routers.proxad.net 14.505ms
6: no reply
Merci Rani ;)
P.S :
J'ai également revérifier la configuration de mon serveur OpenVPN sur ma dédibox, en établissant un tunnel vers un serveur Amazon EC2 en zone Europe, je cartonne bien à plus de 600 Mbit/s en DL / UP sur mon dédié.
Je vais refaire des tests de débits avec iperf3 avec le tunnel OpenVPN de chez moi mais c'est clairement pas cool du tout...
P.S2 : test rejoué avec iperf3 dans les 2 sens, en encapsulant dans un stunnel (ou sans) l'OpenVPN, uniquement en TCP du coup : débit max 180 Mbit/s UP / DL via OpenVPN
Didier
-
La Freebox annonce quel MTU?
-
1/ Un serveur Linux (Ubuntu 14.04 LTS ou Debian 8.3) au cul de la Freebox Mini 4K, impossible d'uploader (speedtest-cli) sans modifier la MTU de l'interface eth0 à 1472.
MTU max à 1472 en IPv4 ou en IPv6 ? Les deux sont indépendants.
Comment cela se passe sous Windows avec une MTU par défaut à 1500 octets ? Il serait intéressant de prendre une capture Wireshark pour comprendre.
fragmentation des paquets par la box ? Pourquoi sous Windows et pas sous Linux ?
-
Si l'IPv4 est encpasulé dans IPv6, et pas l'IPv6, ce dernier devrait avoir un MTU plus grand, normalement 1500.
-
MTU max à 1472 en IPv4 ou en IPv6 ? Les deux sont indépendants.
Comment cela se passe sous Windows avec une MTU par défaut à 1500 octets ? Il serait intéressant de prendre une capture Wireshark pour comprendre.
fragmentation des paquets par la box ? Pourquoi sous Windows et pas sous Linux ?
La stack IPv6 est désactivé sur mon serveur Debian 8 lors de mes tests (et de façon générale en fait).
Et l'option IPv6 n'est pas activée sur la Freebox.
Didier
-
Et pourquoi désactives-tu l'IPv6 ? Dans ton cas elle pourrait bien t'aider. Si c'est une question de sécurité, perso, je n'ai aps encore vu de problème en IPv6. Il faudrait d'ailleurs s'il y a un pare-feu par défaut en IPv6 sur la freebox, mais sous windows, il y a au moins celui du PC. Sous linux, c'est possible aussi.
P.S : underground, tu pourrais suggérer à toriyvaca d'activer l'IPv6, pour voir si cela résout ses problèmes de connexion https et d'authentification Freewifi.
-
Et pourquoi désactives-tu l'IPv6 ? Dans ton cas elle pourrait bien t'aider. Si c'est une question de sécurité, perso, je n'ai aps encore vu de problème en IPv6. Il faudrait d'ailleurs s'il y a un pare-feu par défaut en IPv6 sur la freebox, mais sous windows, il y a au moins celui du PC. Sous linux, c'est possible aussi.
Disons que je n'en vois pas vraiment l'utilité, ni le bénéfice pour mon utilisation actuelle. Maintenant, si pour une obscure raison propre au SI Free, le fait de l'activer permet de nativement bypasser les restrictions que je constate... je vais peut être m'intéresser à basculer mon tunnel VPN sur de l'IPv6.
Pour info, je viens de regarder sous Windows je suis en MTU 1500 par default.
-
Disons que comme l'IPv6 semble la configuration par défaut (l'IPv4 est encapsulé dans l'IPv6), tu as des chances que ton adresse IPv6 soit mieux reconnue (pour se connecter sur le site Freewifi par exemple) que ton adresse IPv4, qui ne serait pas sur ta box...
-
P.S : underground, tu pourrais suggérer à toriyvaca d'activer l'IPv6, pour voir si cela résout ses problèmes de connexion https et d'authentification Freewifi.
Je ne vois pas comment : wifi.free.fr = 212.27.40.236
(et les sites EDF ne semblent pas dispo en IPv6 non plus)
-
Donc en résumant (sans savoir si c'est du DS-Lite) en ZMD chez Free :
- IPv6 native
- IPv4 portée à travers IPv6 avec un mtu de 1472 octets
Du coup le mécanisme qui fait le partage des "ports" entre 4 freebox, ainsi que le tunnel, est déporté sur le NRO?, ou cela se situe directement dans l'infra de Free? (un peu à la manière d'un LNS)
Avec l'IPv6 en natif, et l'IPv4 non natif et partagé, on a "enfin" l'Internet v6 en première classe et le v4 en classe moisie.
-
Disons que je n'en vois pas vraiment l'utilité, ni le bénéfice pour mon utilisation actuelle. Maintenant, si pour une obscure raison propre au SI Free, le fait de l'activer permet de nativement bypasser les restrictions que je constate... je vais peut être m'intéresser à basculer mon tunnel VPN sur de l'IPv6.
Pour info, je viens de regarder sous Windows je suis en MTU 1500 par default.
Donc tu es entrain de dire qu'un traceroute avec un MTU de 1500 fonctionne avec Windows? Il faudrait refaire tes tests effectués précédemment, ça me parait bizarre que ce soit juste Linux qui soit limité à 1472 octets en IPv4 ...
-
Donc en résumant (sans savoir si c'est du DS-Lite) en ZMD chez Free :
- IPv6 native
- IPv4 portée à travers IPv6 avec un mtu de 1472 octets
Du coup le mécanisme qui fait le partage des "ports" entre 4 freebox, ainsi que le tunnel, est déporté sur le NRO?, ou cela se situe directement dans l'infra de Free? (un peu à la manière d'un LNS)
A mon avis, comme le tunnel IPv6 ressort sur un routeur à Courbevoie, et que la freebox ne porterait pas d'IPv4, et que ce serait du DS-Lite, le partage des ports se fait sur ce routeur à Courbevoie.
-
Donc tu es entrain de dire qu'un traceroute avec un MTU de 1500 fonctionne avec Windows? Il faudrait refaire tes tests effectués précédemment, ça me parait bizarre que ce soit juste Linux qui soit limité à 1472 octets en IPv4 ...
Windows est en dual stack par défaut. Le DHCP de la box lui attribuerait une adresse IPv6 avec laquelle il ressortirait directement ?
-
Attention, pour Speedtest, de nombreux serveurs sont par défaut en IPv6 (c'est le cas de celui de Massy par exemple)
Pour revenir sur le DS-Lite :
En DS-Lite, l'ouverture des ports pour l'IPv4, se fait sur l’équipement réseau qui porte l'IPv4 publique, non ?
Si Free faisait du DS-Lite, les paramètres de configuration du NAT dans l'interface de la Freebox server seraient désactivés en IPv4, non ? (modification uniquement par le compte client qui programme l'équipement réseau)
-
Moi je crois plutôt que comme l'ERL n'est pas au courant qu'il n'a pas droit à tous les ports, manque de chance le port source choisi pour les requêtes DNS (si tu utilises dnsmasq sur l'ERL) ne fait pas partie du range qui t'es attribué, et du coup la réponse "va chez ton voisin".
J'espère que les paquets avec les ports non autorisés sont détruits!!!
L'idéal serait de générer un ICMP erreur (dest-unreach? de paramètres?)
-
Windows est en dual stack par défaut. Le DHCP de la box lui attribuerait une adresse IPv6 avec laquelle il ressortirait directement ?
Pardon?
Il y a du DHCPv6 sur la Freebox maintenant?
-
Windows est en dual stack par défaut. Le DHCP de la box lui attribuerait une adresse IPv6 avec laquelle il ressortirait directement ?
Non en IPV4 ça ressort encapsulé en IPv6 mais derrière la box (qui est uniquement en IPv6 native en ZMD).
Du coup cette histoire de MTU est bizarre, faudrait refaire le test, un ping ou traceroute avec Windows vers une IPv4 pour être sur...
-
Pardon?
Il y a du DHCPv6 sur la Freebox maintenant?
Forcèment, si tout passe par un tunnel IPv6. Mais la box elle-même n'est pas forcée de porter une adresse IPv6 adressable de l'extérieur (pas le même VLAN ?).
-
Il y a plusieurs solutions pour attribuer une IPv6 à un client et il me semble que DHCPv6 n'est pas utilisé par Free.
-
En DS-Lite, l'ouverture des ports pour l'IPv4, se fait sur l’équipement réseau qui porte l'IPv4 publique, non ?
Si Free faisait du DS-Lite, les paramètres de configuration du NAT dans l'interface de la Freebox server seraient désactivés en IPv4, non ? (modification uniquement par le compte client qui programme l'équipement réseau)
A mon avis, la gateway DS-Lite laisse tout passer en entrée, c'est la freebox qui bloque ou pas. La gateway se contente juste de mettre IPv4 dans un tunnel IPv6 et l'envoyé
Internet ---> ipv4 dest port X --> gateway DS-lite avec A+P --> ipv4 dans ipv6 vers la box correspondante a X (suivant le 1/4 de ports) --> Freebox (si X ouvert pour entrer ca entre sinon ca bloque ici) --> lan
La gateway est complètement stateless, elle ne track aucune connexion. Elle doit être performante car il y a un trafic important qui passe la.
Dans les faits c'est sans doute du 4rd mais le principe du DS-Lite est plus connu pour comprendre comme ca marche. C'est tres proche sauf que le 4rd fait des tunnels comme le 6rd donc de box a box en IPv6 quand le traffic IPv4 est d'un abonné a l'autre.
la rfc de 2015 a ce sujet: https://tools.ietf.org/html/rfc7600
-
Forcèment, si tout passe par un tunnel IPv6. Mais la box elle-même n'est pas forcée de porter une adresse IPv6 adressable de l'extérieur (pas le même VLAN ?).
Contrairement aux zones ADSL dégroupées qui sont en 6rd, là c'est l'inverse : tout passe en IPv6 native et l'IPv4 est encapsulée dans l'IPv6 avec la freebox (pour la première fois!) mais on cherche quel protocole encapsule l'IPv4. Et pour le coup, le MTU est plus faible, ce qui peut donner un indice sur le proto utilisé. Mais là encore, c'est pas certain certain (d'où mes messages précédents)
-
Attention, pour Speedtest, de nombreux serveurs sont par défaut en IPv6 (c'est le cas de celui de Massy par exemple)
Pour revenir sur le DS-Lite :
En DS-Lite, l'ouverture des ports pour l'IPv4, se fait sur l’équipement réseau qui porte l'IPv4 publique, non ?
Si Free faisait du DS-Lite, les paramètres de configuration du NAT dans l'interface de la Freebox server seraient désactivés en IPv4, non ? (modification uniquement par le compte client qui programme l'équipement réseau)
Oui.
Mais il ne s'agit justement pas de DS-Lite.
-
En ZMD: "Activer IPv6 dans la Freebox" c'est juste coté LAN. Coté WAN ca ne change pas, la freebox ne peut fonctionner sans IPv6.
-
tout les indices pointent vers le 4rd:
1 IP pour 4:
In order to deal with the IPv4 address shortage, customers can be
assigned shared public IPv4 addresses with statically assigned
restricted port sets. As such, it is a particular application of the
Address plus Port (A+P) approach [RFC6346].
et en option une IP full ou plusieurs IP meme :
Deploying 4rd in networks that have enough public IPv4 addresses,
customer sites can also be assigned full public IPv4 addresses. 4rd
also supports scenarios where a set of public IPv4 addresses are
assigned to customer sites.
-
voila le schema de fonctionnement:
4rd Domain
+-----------------------------+
| IPv6 routing |
| Enforced ingress filtering | +----------
... | | |
| +------+
Customer site | |BR(s) | IPv4
+------------+ | BR IPv6 prefix --> |and/or| Internet
| dual-stack | | |N4T64+|
| +--+ | +------+
| |CE+-+ <-- a CE IPv6 prefix | |
| +--+ | | +----------
| | | |
+------------+ | <--IPv4 tunnels--> +------------
=> Derived | (Mesh or hub-and-spoke |
4rd IPv4 prefix| topologies) | IPv6
| | Internet
... | |
| +------------
+-----------------------------+
<== one or several Mapping rules
(e.g., announced to CEs in stateless DHCPv6)
Figure 1: The 4rd Model in the Internet Architecture
-
On n'avait pas eu de confirmation du MTU en IPv4 car personne n'a fait de mesure (ou l'info m'a échappé).
https://lafibre.info/free-la-fibre/installation-freebox-revolution-optique-avec-convertisseur/msg283969/?topicseen#msg283969
https://lafibre.info/free-la-fibre/installation-freebox-revolution-optique-avec-convertisseur/msg283960/?topicseen#msg283960
?
-
Il y a plusieurs solutions pour attribuer une IPv6 à un client et il me semble que DHCPv6 n'est pas utilisé par Free.
Jusqu'à présent, non : l'IPv6 était en 6rd; la config 6rd devrait être inscrite en dur dans le script. (La config 6rd peut aussi être indiquée par DHCP.)
Mais là on passe de v6 dans v4 à v4 dans v6, donc la gestion des adresses change forcèment!
Par ailleurs DHCPv6 peut être utilisé sans que l'utilisateur puisse le savoir, sauf à remplacer la box par un "modem".
-
En ZMD: "Activer IPv6 dans la Freebox" c'est juste coté LAN. Coté WAN ca ne change pas, la freebox ne peut fonctionner sans IPv6.
Il n'y a JAMAIS eu d'option pour désactiver IPv6 SUR la Freebox.
D'ailleurs on ne peut pas non plus contrôler la réponse au ping en IPv6. Il n'y a pas d'option pour ça. (En tout cas pas sur Freebox v5.)
-
Il n'y a JAMAIS eu d'option pour désactiver IPv6 SUR la Freebox.
D'ailleurs on ne peut pas non plus contrôler la réponse au ping en IPv6. Il n'y a pas d'option pour ça. (En tout cas pas sur Freebox v5.)
(http://aide.ma-freebox.fr/ipv6_revo_04.jpg)
ca n'existe plus ?
-
Cela n'a JAMAIS existé!
Désactive IPv6 et envoie moi ton IP.
-
Je te parle coté LAN. ca doit coupé le radvd.
-
Pour revenir sur le DS-Lite :
En DS-Lite, l'ouverture des ports pour l'IPv4, se fait sur l’équipement réseau qui porte l'IPv4 publique, non ?
Si Free faisait du DS-Lite, les paramètres de configuration du NAT dans l'interface de la Freebox server seraient désactivés en IPv4, non ? (modification uniquement par le compte client qui programme l'équipement réseau)
Attention!
DS-Lite = NAPT = stateful
RFC 7600 = IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)
-
Je te parle coté LAN. ca doit coupé le radvd.
Ah oui, on peut éviter d'informer le LAN de l'existence de IPv6.
Mais pas désactiver le support IPv6 sur la Freebox, ni le ping.
-
Au final il y a un process de changement totalement inversé entre Free et Orange : en ZMD, Free part sur du 4rd géré par un/des gros routeur, plusieurs gateway IPv4 centralisées, tandis qu'Orange supprime progressivement les BAS et adresse plus localement.
La question, c'est de savoir si le 4rd et A+P va se généraliser sur l'ensemble du réseau de Free, ou si cela va rester uniquement sur les ZMD? (sachant qu'il faut avoir l'IPv6 en natif)
Si Rani pourrait nous éclairer, ça serait super ;)
-
Free/Orange :
(https://upload.wikimedia.org/wikipedia/commons/thumb/1/17/Yin_yang.svg/240px-Yin_yang.svg.png?uselang=fr)
-
Si on a réellement MTU=1472 en IPv4, en TCP il suffit que la Freebox modifie le MSS, donc les problèmes sous Linux sont étranges.
Est-ce qu'on a des captures côté serveur ?
-
Il me semble évident que la Freebox doit modifier le MSS dans les paquets [SYN] et [SYN-ACK] de TCP, comme c'est le cas en zone non dégroupée (40 octets de perdu par le tunnel L2TP)
Je suis à disposition pour faire des traces serveur pendant qu'une personne fait des traces coté client avec un MTU à 1500 octets.
-
En mode bridge, le MSS est quand même ajusté par la freebox?
Il semble que notre ami utilise sa box en mode bridge
-
Mode soi-disant bridge...
-
Il y a un point qui ne me parait pas clair dans ce qui a été dit dans ce sujet, c'est l'histoire du MTU. D'après les liens cités par Marin, cyberjuls avait mesuré un MTU de 1500, aussi bien en linux qu'en windows :
https://lafibre.info/free-la-fibre/installation-freebox-revolution-optique-avec-convertisseur/msg283969/?topicseen#msg283969
https://lafibre.info/free-la-fibre/installation-freebox-revolution-optique-avec-convertisseur/msg283960/?topicseen#msg283960
Didjee34 parle d'un MTU de 1472 quand il est en Linux, et de 1500 quand il teste avec windows, ce qui, comme l'a relevé Darklight, ne paraît pas cohérent.
D'autre part, j'ai trouvé un lien qui semble indiquer que l'en-tête d'un tunnel IPv6 pour l'IPv4 serait de 40 octets (en particulier pour DS-lite, mais je pense que c'est la même chose pour 4rd ?) :
http://www.networkworld.com/article/2224654/cisco-subnet/mtu-size-issues.html
Par ailleurs, 1472 est une valeur particulière, c'est celle du paquet ICMP, auquel il faut rajouter 20 octets pour l'en-tête IP, et 8 pour ICMP, pour faire justement 1500 octets...
En fait, est-ce que l'on ne serait pas avec un MTU standard de 1500, et les conditions de didjee34 (mode bridge), induirait une erreur sous Linux ?
Ce qui me fait dire cela, c'est que je viens de lire dans la description du protocole DS-Lite, qu'il est recommandé d'ajouter 40 octets, justement pour que la trame IPv4 fasse toujours 1500 :
Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4 traffic over IPv6 will reduce the effective MTU of the datagram.
Unfortunately, path MTU discovery [RFC1191] is not a reliable method to deal with this problem.
A solution to deal with this problem is for the service provider to increase the MTU size of all the links between the B4 element and the
AFTR elements by at least 40 bytes to accommodate both the IPv6 encapsulation header and the IPv4 datagram without fragmenting the
IPv6 packet.
http://tools.ietf.org/html/rfc6333 Paragraphe 5.3
P.S : si c'était vrai, cela voudrait dire que le MTU en IPv6 serait de 1540, ce qu'il est possible de vérifier.
-
Je ne suis pas convaincu que les bons tests de mtu ont été fait (ping avec DF=1).
Le 4rd fragmente de lui meme un paquet IPv4 trop grand (coté freebox en sortie ou coté gateway en entrée).Donc on ne voit rien de spécial si on ne sait pas faire un bon test. Il ne faut pas confondre IPv6 = "on ne fragmente pas entre les 2 bouts" et IPv4 = "on peut fragmenter entre les 2 bouts".
R-14: If an IPv4 packet enters a CE or BR with a size such that the
derived Tunnel packet would be longer than the Domain PMTU, the
packet has to be either discarded or fragmented. The
Domain-entry node MUST discard it if the packet has DF = 1,
with an ICMP error message returned to the source. It MUST
fragment it otherwise, with the payload of each fragment not
exceeding PMTU - 48. The first fragment has its offset equal
to the received offset. Subsequent fragments have offsets
increased by the lengths of the payloads of previous fragments.
Functionally, fragmentation is supposed to be done in IPv4
before applying reversible header translation to each fragment;
see Section 4.3.
-
En tout cas, le MTU du paquet IPv4 ne peut pas être de 1472, avec un MTU "normal" de 1500, car l'en-tête d'un paquet IPv6 fait au minimum 40 octets, auquel peut se rajouter éventuellement d'autres informations, comme par exemple le type de protocole transporté, etc...
https://en.wikipedia.org/wiki/IPv6_packet
Si en IPv4, le MTU est de 1472, la taille du paquet IPv6 qui l'encapsule est au minimum de 1472 + 40 = 1512.
Rq : je ne vois pas comment si le paquet IPv6 n'est pas fragmenté entre les deux bouts, comment le paquet IPv4 pourrait l'être. A mon avis, il ne peut être fragmenté qu'avant l'entrée dans le tunnel, avant l'encapsulation. Si le paquet IPv6 peut être fragmenté, alors sa charge, le paquet IPv4 le sera aussi, même si c'est reconstitué plus loin.
P.S : En 6rd, le paquet IPv6 est encapsulé dans une trame IPv4. Comme l'en-tête du paquet IPv4 est de 20 octets, le MTU du paquet IPv6 est de 1480.
-
Qui a dit qu'un paquet IPv4 était la charge utile d'un paquet IPv6?
-
Si le paquet IPv4 est réparti entre deux paquets IPv6, il est fragmenté, non ? S'il n'est pas fragmenté, il est dans une seule trame IPv6 ?
Voir la référence sur DS-Lite que j'ai donnée plus haut.
-
Oui, si le paquet est découpé dans plusieurs paquets lors de l'encapsulation, ça compte moralement comme une fragmentation.
-
Plus que moralement, si l'un des paquets est perdu, tu demandes de renvoyer quoi ?
-
Si un paquet est perdu, et comme ce protocole d'encapsulation ne prévoit pas de faire des retransmissions, le tout est perdu.
Il y a des cas où le protocole d'encapsulation est basé sur TCP (ce que propose OVH) et donc gère lui même les retransmissions.
Il y a aussi le cas du Wifi qui découpe les paquets et qui gère les retransmissions, ainsi que l'ADSL. Dans ces deux cas l'opération est transparente.
-
Oui, c'est possible. En tout cas, si la répartition d'une trame IPv4 entre deux trames IPv6 est bien comptée comme une fragmentation, ce qui serait naturel, alors si le MTU IPv4 est de 1500 octets, celui IPv6 est d'au moins 40 octets de plus, l'en-tête d'une trame IPv6, donc 1540.
-
Encore une fois, non!
Qui a dit qu'un paquet IPv4 était la charge utile d'un paquet IPv6?
-
Et encore ? Si tu prenais le temps de t'expliquer ?
-
en 4rd un paquet IPv4 n'est pas entier dans le payload IP d'un paquet IPv6.
Il y a un mapping reversible entre les entêtes IPv4 et les entêtes IPv6 et le payload IP est inchangé.
Suivant les cas on peut avoir besoin de place supplèmentaire (8 octets dans le cas présent), dans ce cas la norme IPv6 permet d'utiliser ce qu'on appelle un "IPv6 Fragment Header" pour avoir plus de place.
(A) Without IPv6 fragment header
IPv4 packet Tunnel packet
+--------------------+ : : +--------------------+
20| IPv4 Header | : <==> : | IPv6 Header | 40
+--------------------+ : : +--------------------+
| IP Payload | <==> | IP Payload |
| | Layer 4 | |
+--------------------+ unchanged +--------------------+
(B) With IPv6 fragment header
Tunnel packet
: +--------------------+
IPv4 packet : | IPv6 Header | 40
+--------------------+ : : +--------------------+
20| IPv4 Header | : <==> : |IPv6 Fragment Header| 8
+--------------------+ : : +--------------------+
| IP Payload | <==> | IP Payload |
| | Layer 4 | |
+--------------------+ unchanged +--------------------+
Ca n'est donc pas un tunnel comme en DS-lite, c'est un tunnel comme en 6rd mais ou les roles sont inversés.
lisez la RFC https://tools.ietf.org/html/rfc7600 si vous voulez tout les détails du mapping entre entêtes.
-
Et encore ? Si tu prenais le temps de t'expliquer ?
Pourquoi tu poses comme hypothèse l'approche la plus lourde en terme de surcharge protocolaire?
Tu supposerais que quand une marchandise arrive par camion, le camion est arrivé sur un train, le train sur la bateau et le bateau sur un avion (ou inversement)?
-
en 4rd un paquet IPv4 n'est pas entier dans le payload IP d'un paquet IPv6.
Il y a un mapping reversible entre les entêtes IPv4 et les entêtes IPv6 et le payload IP est inchangé.
Suivant les cas on peut avoir besoin de place supplèmentaire (8 octets dans le cas présent), dans ce cas la norme IPv6 permet d'utiliser ce qu'on appelle un "IPv6 Fragment Header" pour avoir plus de place.
(A) Without IPv6 fragment header
IPv4 packet Tunnel packet
+--------------------+ : : +--------------------+
20| IPv4 Header | : <==> : | IPv6 Header | 40
+--------------------+ : : +--------------------+
| IP Payload | <==> | IP Payload |
| | Layer 4 | |
+--------------------+ unchanged +--------------------+
(B) With IPv6 fragment header
Tunnel packet
: +--------------------+
IPv4 packet : | IPv6 Header | 40
+--------------------+ : : +--------------------+
20| IPv4 Header | : <==> : |IPv6 Fragment Header| 8
+--------------------+ : : +--------------------+
| IP Payload | <==> | IP Payload |
| | Layer 4 | |
+--------------------+ unchanged +--------------------+
Ca n'est donc pas un tunnel comme en DS-lite, c'est un tunnel comme en 6rd mais ou les roles sont inversés.
lisez la RFC https://tools.ietf.org/html/rfc7600 si vous voulez tout les détails du mapping entre entêtes.
Si je comprends bien, le mapping permet de faire tenir l'en-tête IPv4 dans celui IPv6. Donc de combien est l'en-tête dans le cas de l'encapsulation 4rd, si on retire ce qui est commun avec IPv4 ? Comme l'en-tête IPv6 est de 40 octets, et celui IPv4 de 20 octets, cela ferait encore +20, et donc éventuellement le fragment header de 8, donc 28 ? Dans ce cas, on arriverait effectivement à 2472.
-
oui si on veut éviter de la fragmentation il faut mettre un MTU a 1472. Mais en IPv4 ca n'est pas nécessaire de chercher a éviter la fragmentation.
-
Pourquoi tu poses comme hypothèse l'approche la plus lourde en terme de surcharge protocolaire?
Tu supposerais que quand une marchandise arrive par camion, le camion est arrivé sur un train, le train sur la bateau et le bateau sur un avion (ou inversement)?
En tout cas, c'est bien ce qu'il semble se passer dans un tunnel 4in6 :
IPv6 encapsulation consists of prepending to the original packet an IPv6 header and, optionally, a set of IPv6 extension headers
Voir : https://tools.ietf.org/html/rfc2473#section-3.1
D'où la recommandation sur DS-Lite que j'ai déjà citée :
A solution to deal with this problem is for the service provider to increase the MTU size of all the links between the B4 element and the
AFTR elements by at least 40 bytes to accommodate both the IPv6 encapsulation header and the IPv4 datagram without fragmenting the
IPv6 packet.
http://tools.ietf.org/html/rfc6333#section-5.3
Si tu étais un peu plus aimable ? Je préfère les explications détaiallées de kgersen.
-
oui si on veut éviter de la fragmentation il faut mettre un MTU a 1472. Mais en IPv4 ca n'est pas nécessaire de chercher a éviter la fragmentation.
Mais on voit quand même avec ce MTU, ce qui était le but de opération, qu'il y a encapsulation dans un tunnel, et donc ce serait bien 4rd.
Maintenant, pourquoi en windows, ce serait quand même 1500 ? (et peut-être aussi sous linux avec cyberjuls).
L'autre solution, pour rester avec un MTU de 1500 en IPv4, serait d'augmenter le MTU IPv6 de 28, donc 1528.
-
Je me répète mais on est certain des tests déja effectués?
le test canonique sous Windows est:
ping -4 -f -l 1472 lafibre.info
ce qui donne un MTU couche IP de 1500 (ping de 1472 + 8 icmp + 20 entete IPv4)
y'aurait pas une confusion du niveau du MTU (couche 3, couche 4) quelque part dans les échanges entre personnes ici ?
un MTU couche IP de 1472 c'est un ping de ping de 1444 (- 8 icmp - 20 entete IPv4)
donc
ping -4 -f -l 1444 lafibre.infodoit passer
et
ping -4 -f -l 1445 lafibre.infone doit pas passer
-
Et encore ? Si tu prenais le temps de t'expliquer ?
Expliquer quoi?
J'ai tout dit. Tu fais une hypothèse que tu considères comme en soi évidente.
Je ne pense pas qu'elle le soit. Si elle l'est, démontre le!
-
"elle" ?
Quelle hypothèse ? Commence par expliquer ça, ce sera plus simple de te suivre.
-
Plus que moralement, si l'un des paquets est perdu, tu demandes de renvoyer quoi ?
Qui demande de renvoyer?
TCP? DNS? NFS?
En général, on demande au moins tout ce qu'on n'a pas reçu.
-
"elle" ?
Quelle hypothèse ? Commence par expliquer ça, ce sera plus simple de te suivre.
Cette hypothèse :
En tout cas, le MTU du paquet IPv4 ne peut pas être de 1472, avec un MTU "normal" de 1500, car l'en-tête d'un paquet IPv6 fait au minimum 40 octets, auquel peut se rajouter éventuellement d'autres informations, comme par exemple le type de protocole transporté, etc...
https://en.wikipedia.org/wiki/IPv6_packet
Si en IPv4, le MTU est de 1472, la taille du paquet IPv6 qui l'encapsule est au minimum de 1472 + 40 = 1512.
Il dit qu'un paquet IPv4 est la charge utile d'un paquet IPv6, au moins (peut être d'autres informations sont ajoutées).
-
Merci.
-
Si on raisonne en terme d'entropie, je pense que c'est plus clair.
-
Je ne suis pas convaincu que les bons tests de mtu ont été fait (ping avec DF=1).
Le test de cyberjuls était avec mturoute, qui positionne DF.
Mais comme ça semble tout de même en beta, rien ne dit que Free n'a pas changé des choses depuis.
Il y a peut-être aussi des bugs dans la Freebox, et le mode bridge est certainement moins testé.
Je pense qu'on y verrait plus clair en comparant les paquets capturés côté client et serveur (Vivien s'est proposé) dans les différentes configurations, même si l'idéal serait de voir ce qui transite entre le Freebox et le module SFP.
-
si la répartition d'une trame IPv4 entre deux trames IPv6 est bien comptée comme une fragmentation,
La répartition (terme bien trouvé!) EN SOI n'est pas une fragmentation ni pas-une-fragmentation.
C'est le comportement du système de transport du protocole machin au dessus du protocole trucmuche qui cause ou pas une fragmentation :
- si un paquet machin rentre d'un coté et deux ressortent alors c'est une fragmentation
- si un seul paquet ressort dans tous les cas, alors ce n'est pas forcèment une fragmentation
Le protocole ADSL transporte des trames ATM (ou autre) qui sont petites. Il y a répartition des trames PPP ou Ethernet ou IP mais il n'y a pas de fragmentation. C'est invisible pour la couche IP.
Le protocole Wifi découpe les trames Wifi=Ethernet en petites bouchées. Il y a répartition et pas fragmentation. C'est invisible pour la couche IP.
Pour que le découpage ne génère pas une fragmentation il faut que les trames soient reconstituées à l'autre bout. Si c'est le cas, on peut dire qu'il n'y a pas fragmentation.
Cependant, si les performances sont divisées par deux quand on augmente le MTU au delà d'une limite qui est haute, alors il faut classer ça comme fragmentation : imaginons un système utilisant 6in4 avec découpage des paquets trop grands et ré-assemblage des paquets IPv6 de l'autre coté. Sur un lien Ethernet ordinaire, on aurait MTU IPv4 = 1500; mettons que la MTU IPv6 est fixée par Ethernet à 1500, alors les paquets IPv6 jusqu'à 1480 passeront en une fois et ceux à partir de 1481 en deux fois. C'est ridicule parce que 1480 est une grande valeur et que la surcharge protocolaire grimpe énormèment.
D'un autre coté, imaginons un protocole qui transmet les paquets en découpant en blocs de 510 octets. Dans ce cas, ça n'a aucun sens de baisser la MTU.
-
Je me répète mais on est certain des tests déja effectués?
Peut-être pas, tous les tests n'ont pas montré la ligne de commande utilisée. Ce serait bien de les refaire. Et surtout en IPv4 ET en en IPv6, pour voir s'il y a une différence.
-
en 4rd un paquet IPv4 n'est pas entier dans le payload IP d'un paquet IPv6.
Il y a un mapping reversible entre les entêtes IPv4 et les entêtes IPv6 et le payload IP est inchangé.
Disons que c'est du NAT464 1:1
Suivant les cas on peut avoir besoin de place supplèmentaire (8 octets dans le cas présent), dans ce cas la norme IPv6 permet d'utiliser ce qu'on appelle un "IPv6 Fragment Header"
Plus précisèment la norme IPv6 ne dit rien : un champs "id" n'a pas plus de sémantique qu'un numéro de port (même moins).
pour avoir plus de place.
Je ne vois pas pourquoi tu parles de "place". Il s'agit juste de ne pas introduire un type de paquet différent pour le 4rd et d'utiliser des types existants.
C'est de la surcharge tout simplement.
Cela évite d'avoir à faire un enregistrement officiel IANA et d'utiliser une ressource en numérotation.
-
La consequence d'utiliser du 4rd donc du partage d'header entre IP4 et IPv6 a des conséquences sur un traceroute en IPv4: celui ci affiche les nœuds IPv6 intermédiaires en IPv4 (adresse bidon)...contrairement a un vrai tunnel qui masque les nœuds intermédiaires.
Détails:
The effect of this TTL treatment on IPv4 traceroute is specific:
(1) the number of routers of the end-to-end path includes traversed
IPv6 routers; (2) IPv6 routers of a Domain are listed after IPv4
routers of Domain entry and exit; (3) the IPv4 address shown for an
IPv6 router is the IPv6-only dummy IPv4 address (Section 4.8 );
(4) the response time indicated for an IPv6 router is that of the
next router
trad:
Les effets qu'a ce traitement particulier du TTL sur un traceroute IPv4 sont:
(1) le nombre de routeurs de bout en bout inclus les routeurs IPv6 traversés.
(2) les routeurs IPv6 du Domaine (=zone dans laquelle IPv4 est en "tunnel") sont listés après les routeurs IPv4 d'entree et de sortie du Domaine.
(3) l'IPv4 affichée pour un routeur IPv6 est la fausse IPv4 du 4rd (adresse réservée explicitement par l'IANA et valant 192.0.0.8/32).
(4) le temps de réponse qu'indique un routeur IPv6 est celui du prochain routeur
li serait intéressant d'avoir un traceroute IPv4 d'un abonné en ZMD Free pour voir si on peut constater cela.
traceroute dest:
PC
IPv4 freebox
IPv4 gateway 4rd
192.0.0.8 (R1) (ou pas de reponse?)
...
192.0.0.8 (Rn)
next hop IPv4
...
dest
PC -- lan -- (IPv4)freebox(IPv6) --- Routeur IPv6 R1 -- ... -- Routeur IPv6 Rn-- (IPv6)gateway 4rd (IPv4) -- next hop IPv4 ... Internet 4 ... dest
enfin, si j'ai bien compris ce passage et si Free respecte a 100% la rfc du 4rd.
-
Pour que le découpage ne génère pas une fragmentation il faut que les trames soient reconstituées à l'autre bout. Si c'est le cas, on peut dire qu'il n'y a pas fragmentation.
Le fait de découper les paquets et les reconstituer à l'autre bout génère une forte charge CPU sur les routeurs qui font ce travail.
Cela génère aussi de la gigue, les petits paquets qui ne nécessitent pas d'être découpés arrivent avant les plus gros qui sont passés par l'étape fragmentation / reconstitution.
Une capture wireshark permet de voir si ce type de comportement est effectué.
Il est plutôt conseillé de baisser la MSS dans les en-têtes TCP (modification du champ MSS des paquets TCP SYN et paquets TCP SYN-ACK).
-
li serait intéressant d'avoir un traceroute IPv4 d'un abonné en ZMD Free
- https://lafibre.info/free-la-fibre/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/msg283352/?topicseen#msg283352
- https://lafibre.info/free-la-fibre/ftth-zmd-free-fait-du-ds-lite/msg311808/?topicseen#msg311808
-
Rq : dans ces deux cas (cyberjuls et didjee34, à Castelnau Le Lez), on passe d'abord par l'adresse IPv4 194.149.164.0, puis on sort par le routeur de Bezons, p11-crs16-1-be1003.intf.routers.proxad.net. L'adresse IPv4 est pingable. Je ne sais pas à quoi correspond cette adresse IPv4. Quand je fais un traceroute, je l'atteins à travers le même routeur. Par contre, elle ne semble pas avoir de reverse DNS. Est-ce que c'est l'adresse d'une des interfaces du routeur, liée au "tunnel" 4rd ? l'adresse appartient à Online, dans la plage 194.149.160.0/19. J'ai l'impression que c'est cette adresse qui sert à la translation IPv6 vers IPv4.
P.S : cela pourrait correspondre à cette partie de la réponse de kgersen, mais sans utiliser l'adresse réservée par IANA ?
(3) l'IPv4 affichée pour un routeur IPv6 est la fausse IPv4 du 4rd (adresse réservée explicitement par l'IANA et valant 192.0.0.8/32).
P.S 2 : je remets le tracepath de didjee34 pour plus de clarté, à partir de son debian 8 :
MTU 1472
root@vpnbox:~# ifconfig eth0 mtu 1472
root@vpnbox:~# tracepath www.free.fr
1?: [LOCALHOST] pmtu 1472
1: 192.168.2.1 0.322ms
1: 192.168.2.1 0.260ms
2: 194.149.164.0 13.980ms
3: p11-crs16-1-be1003.intf.routers.proxad.net 18.045ms
4: p11-9k-1-be1000.intf.routers.proxad.net 15.521ms
5: bzn-9k-2-sys-be2001.intf.routers.proxad.net 14.505ms
6: no reply
-
mouais pas tres concluant. y'a peut-etre un écart de mise en oeuvre chez Free.
-
Je vois aussi que l'adresse 192.0.2.1 apparait dans le traceroute. Or le bloc 192.0.2.0/24 est réservé par IANA pour des documentations :
3. Documentation Address Blocks
The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),
and 203.0.113.0/24 (TEST-NET-3) are provided for use in
documentation.
http://tools.ietf.org/html/rfc5737#section-3
Il est possible que Free ait ré-utilisé dans son implèmentation des adresses vues dans une documentation, et réservées pour cela...
-
Bon, voici les résultats des tests réalisés sur la connexion Free de mon voisin.
Machine utilisée : DELL Precision M6600, i7 quadri coeur, 8 Gb de RAM et SSD connectée en direct en câble à la Freebox.
Speedtest :
(https://www.speedtest.net/result/5124828398.png)
Constatations :
-Le débit IPv6 est ridicule, de ce fait je n'ai pas pu terminer le test de neutralité
-Certains sites sont long à charger
-La MTU en IPv4 est de 1474
-La MTU en IPv6 est de 1480 1500
-Je n'ai pas pu me connecter au FTP de testdebit.info en IPv4 (encore une histoire de plage de port ça)
-Impossible d'activer le VPN de la Freebox, un truc du style "Vous ne pouvez pas activer cette fonctionnalité avec votre connexion" c'est sacrèment con de migrer sur la fibre pour au final pas pouvoir accéder à ton réseau
-L'espace client n'est pas du tout à jour, c'est comme si la migration fibre n'avait jamais été faite
-Le débit du Speedtest est bien limité par la connexion et non le PC, qui fait 950 Mb/s en FTTH SFR.
Des traceroutes :
Target Name: massy.testdebit.info
IP: 194.158.102.114
Date/Time: 28/02/2016 16:54:53 to 28/02/2016 16:55:09
Hop Sent Err PL% Min Max Avg Host Name / [IP]
1 16 0 0,0 0 0 0 FREEBOX [192.168.0.254]
2 16 0 0,0 3 3 3 [194.149.164.0]
3 16 0 0,0 4 12 7 cbv-crs8-1-be1005.routers.proxad.net [78.254.249.78]
4 16 0 0,0 3 5 3 th2-9k-1-be1003.intf.routers.proxad.net [78.254.249.97]
5 15 2 13,3 3 4 3 la110.rpt02-th2.net.bbox.fr [194.117.192.9]
6 16 0 0,0 3 4 3 [194.158.102.114]
Target Name: free.fr
IP: 212.27.48.10
Date/Time: 28/02/2016 16:55:17 to 28/02/2016 16:55:30
Hop Sent Err PL% Min Max Avg Host Name / [IP]
1 11 0 0,0 0 0 0 FREEBOX [192.168.0.254]
2 10 0 0,0 3 3 3 [194.149.164.0]
3 10 0 0,0 4 12 6 p11-crs16-1-be1003.intf.routers.proxad.net [78.254.249.101]
4 10 0 0,0 3 5 3 p11-9k-1-be1000.intf.routers.proxad.net [78.254.249.130]
5 10 0 0,0 3 3 3 bzn-9k-2-sys-be2001.intf.routers.proxad.net [194.149.161.246]
6 10 0 0,0 3 4 3 www.free.fr [212.27.48.10]
Et le bon vieux HE.net qui ne va pas en s'arrangeant...
Target Name: tserv1.par1.he.net
IP: 216.66.84.42
Date/Time: 28/02/2016 16:58:11 to 28/02/2016 16:58:22
Hop Sent Err PL% Min Max Avg Host Name / [IP]
1 9 0 0,0 0 0 0 FREEBOX [192.168.0.254]
2 9 0 0,0 3 3 3 [194.149.164.0]
3 9 0 0,0 3 9 6 cbv-crs8-1-be1005.routers.proxad.net [78.254.249.78]
4 9 0 0,0 3 3 3 th2-9k-1-be1003.intf.routers.proxad.net [78.254.249.97]
5 9 0 0,0 84 84 84 yankee-6k-1-po1.intf.routers.proxad.net [212.27.57.14]
6 9 0 0,0 84 84 84 newyork-6k-1-po2.intf.routers.proxad.net [212.27.58.209]
7 9 0 0,0 153 281 183 paloalto-6k-1-po1.intf.routers.proxad.net [212.27.58.222]
8 6 6 100,0 0 0 0 [-]
9 9 0 0,0 153 159 154 10ge7-5.core1.sjc2.he.net [72.52.92.70]
10 8 0 0,0 151 160 152 100ge1-2.core1.nyc4.he.net [184.105.81.214]
11 8 0 0,0 148 154 149 100ge11-1.core1.par2.he.net [184.105.81.78]
12 8 0 0,0 149 157 151 10ge3-1.core1.par1.he.net [184.105.213.89]
13 8 0 0,0 148 149 148 tserv1.par1.he.net [216.66.84.42]
-
Très intéressant. Merci Slotthy. C'est la première fois que nous avons des tests en IPv4 et IPv6 en même temps, et aussi en windows.
Pour ta détermination du MTU, si je comprends bien, tu recherches le ping le plus long qui passe. Sous IPv4, tu as donc trouvé 1446. Si on rajoutes 20 octets d'en-tête IPv4 + 8 ICMP, on a bien 1446 + 20 +8 = 1474. Je suis étonné, je m'attendais à 1472, comme didjee34...
En IPv6, tu obtiens 1452. Pour moi, cela ne fait pas un MTU de 1480, mais de 1500, car l'en-tête IPv6 est de 40 octets, pas de 20 comme en IPv4. Donc, 1452 + 40 +8 = 1500. Donc on obtient un MTU normal de 1500 octets.
Cela confirme que l'IPv4 est encapsulé dans de l'IPv6, car la taille de la trame IPv6 est bien supérieure à celle IPv4, donc cela correspond bien plutôt à du 4rd. J'ai une interrogation sur la valeur de 1474 en IPv4, car on aurait du avoir 40 (header IPv6) - 20 (header IPv4 compris dans l'en-tête IPv6) + 8 (IPv6 fragmentation header), donc 28 à retrancher à 1500, donc 1472..
En tout cas, cela confirme aussi, comme c'est normal, que le MTU IPv4 sous windows n'est pas de 1500, mais donc ici de 1474. Pas de diffréence de comportement avec linux.
D'autre part, dans le traceroute, on passe aussi par l'adresse IPv4 194.149.164.0, comme à Castelnau, ce qui montre que cela ne dépend pas de l'emplacement, et que c'est probablement l'adresse IPv4 de sortie du tunnel IPv6, et que c'est toujours le même routeur final qui est utilisé.
-
Exact pour le MTU en IPv6, j'ai été un peu vite ;)
-
Je viens de revoir que cyberjuls avait bien fait des tests en IPv6, et obtenait aussi un PMTU de 1500 :
https://lafibre.info/free-la-fibre/installation-freebox-revolution-optique-avec-convertisseur/msg283960/#msg283960
-
Je n'avais pas fait attention aux remarques que tu as faites, concernant le FTP de testdebit que tu n'as pas pu contacter, tu as essayé avec quel logiciel, Filzilla ? C'est peut-être une histoire de FTP passif vs actif ? En passif, les ports d’échange des données sont ouverts sur le serveur, donc cela ne devrait pas avoir d'importance le port d'où tu pars, à condition que le serveur testdebit le permette (ou son pare-feu) ?
P.S 2 : je remarque dans ta capture d'écran que le FTP passe bien en passif, mais pas de réponse du serveur.
Pour le VPN, c'est encore à priori un problème d'authentification de l'adresse de la freebox, en 91.160.13.x, qui n'est là non plus pas autorisée. Pour l'interface de gestion, il faut voir si elle va s'actualiser dans les jours à venir.
P.S : c'est étonnant que tu dises que le débit IPv6 est ridicule, surtout vu le test de débit que tu affiches, 720 Mb/s en download, 325 en upload. Normalement le débit en IPv6, natif, devrait être supérieur à celui en IPv4, encapsulé, à moins que le serveur ne soit pas en IPv6 ?
-
Le SpeedTest de Massy est normalement réalisé en IPv6, si IPv6 est disponible. (il faudrait une capture wireshark pour confirmer)
Sinon vous pouvez utiliser nperf qui permet de faire un test IPv4 et un test IPv6 sur le serveur de Massy.
Serait-il possible de donner les MSS en IPv4 et en IPv6 ?
Je donne quelques exemples ici avec SFR en IPv4 et IPv6 : Négociation MTU MSS: comment ça fonctionne? (https://lafibre.info/tcpip/negociation-mtu-comment-ca-fonctionne/12/)
-
Effectivement, Massy fonctionne en IPv6, par contre le Speedtest a été effectué en IPv4, car par défaut l'IPv6 n'était pas activé.
Oui, j'ai essayé avec Filezilla, et on voit bien "Entering passive Mode" avant que ça bloque donc il a tenté en passif.
Pour le VPN IKEv2, il y a les port 500 et 4500 qui doivent être disponibles aussi pour que ça fonctionne, et le 1723 en PPTP et vu que je n'ai pas droit à ces ports la...
Pour le débit en IPv6 en tout cas il semblait y avoir une limitation à ~9 Mb/s / thread, confirmé par les téléchargements FTP simultanés sur 1.testdebit.info et le test de neutralité. Maintenant, c'est vrai qu'il aurait été intéressant de tester un autre serveur en IPv6, car les différents tests ont visé la même destination.
Pour les tests de MSS je vais pas pouvoir prochainement, désolé ;D
-
La consequence d'utiliser du 4rd donc du partage d'header entre IP4 et IPv6 a des conséquences sur un traceroute en IPv4: celui ci affiche les nœuds IPv6 intermédiaires en IPv4 (adresse bidon)...contrairement a un vrai tunnel qui masque les nœuds intermédiaires.
Comme du NAT!
-
Je vois aussi que l'adresse 192.0.2.1 apparait dans le traceroute. Or le bloc 192.0.2.0/24 est réservé par IANA pour des documentations :
http://tools.ietf.org/html/rfc5737#section-3
Il est possible que Free ait ré-utilisé dans son implèmentation des adresses vues dans une documentation, et réservées pour cela...
c'est étrange étant donné qu'il y a une plage d'adresse réservé à cette utilisation spécifique
https://isc.sans.edu/diary/RFC+6598+-+Carrier+Grade+NAT/20777
https://tools.ietf.org/html/rfc6598
-
Pour le débit en IPv6 en tout cas il semblait y avoir une limitation à ~9 Mb/s / thread, confirmé par les téléchargements FTP simultanés sur 1.testdebit.info et le test de neutralité. Maintenant, c'est vrai qu'il aurait été intéressant de tester un autre serveur en IPv6, car les différents tests ont visé la même destination.
Voici d'autres serveurs, dispo sur https://testdebit.info/ Online, OVH, ... il y a du choix.
et même l'hébergeur ikoula : remplace le "1" de 1.testdebit.info par "ikoula"
-
Vivien, Slotthy a fait les tests chez un voisin qui vient juste d'avoir la fibre en ZMD, donc il n'a peut-être pas la possibilité d'y retourner de sitôt...
-
Le fait de découper les paquets et les reconstituer à l'autre bout génère une forte charge CPU sur les routeurs qui font ce travail.
Et surtout cela demande de stocker un temps indéfini les fragments qui arrivent, avec un timeout "raisonnable", on arrive à un charge mémoire maximum énorme.
En pratique les paquets arrivent plutôt rapidement et proche les uns des autres, mais ça permet de faire une attaque DOS très facilement ce qui va au moins forcer des purges mémoires plus fréquentes (au pire saturer toutes la mémoire et faire bugger la passerelle) et rendre la défragmentation moins efficace.
C'est un défaut générique de la fragmentation IP. Le fait que ce soit une passerelle au cœur du réseau ne ferait qu'empirer le problème.
Un autre problème de la fragmentation IP est pour les NAPT : il faut défragmenter pour avoir les paquets TCP/UDP/... complets afin de faire correspondre chaque paquet à une règle de NAT.
De même de façon plus générale, c'est le cas dès qu'on veut faire du suivi de connexions (conntrack sous linux) : l'activation de conntrack active la défragmentation de tous les paquets automatiquement.
De même de façon encore plus générale, quand on veut appliquer un filtre sur les ports dans le pare-feu. Mais là on peut éventuellement tolérer que les fragments supplèmentaires ne soient pas filtrés, vu qu'ils ne seront jamais complétés si le premier paquet est rejeté.
Cela génère aussi de la gigue, les petits paquets qui ne nécessitent pas d'être découpés arrivent avant les plus gros qui sont passé par l'étape fragmentation / reconstitution.
Pas forcèment.
Les gros paquets n'arrivent pas après les petits en Wifi, que je sache.
-
Il y a quelque chose de bizarre dans le test de MTU de Slothy : normalement le ping trop gros devrait sortir "Le paquet doit être fragmenté mais paramétré DF.".
Peut-être que la Freebox ne répond pas, au lieu d'envoyer un ICMP type 3 (Destination Unreachable) code 4 (fragmentation needed and DF set).
Si c'est le cas, ça pourrait expliquer les problèmes sous Linux en IPv4 (https://tools.ietf.org/html/rfc2923), si la Freebox n'ajuste pas le MSS non plus.
Peut-être que Windows détecte ce genre de situations et désactive le PMTU Discovery (et donc ne positionne plus DF sur les paquets de la connexion TCP), ce qui fait que ça fonctionne, mais en fragmentant.
-
la sous-discussion sur FTP est déplacée ici: https://lafibre.info/tcpip/partage-de-ports-mode-de-fonctionnement-de-ftp/
-
Bon, voici les résultats des tests réalisés sur la connexion Free de mon voisin.
Machine utilisée : DELL Precision M6600, i7 quadri coeur, 8 Gb de RAM et SSD connectée en direct en câble à la Freebox.
Speedtest :
(https://www.speedtest.net/result/5124828398.png)
-Le débit IPv6 est ridicule, de ce fait je n'ai pas pu terminer le test de neutralité
-Le débit du Speedtest est bien limité par la connexion et non le PC, qui fait 950 Mb/s en FTTH SFR.
Avec un PC (Windows 7 et Firefox) moins performant j'ai les mêmes résultats que toi.
Quel OS et navigateur utilises tu?
-
Windows 10 et Firefox.
-
Hello,
Je n'ai pas eut le temps ce week end de m'y remettre, mais concernant sous Linux le Path MTU Discovery, il faut je pense tester ça :
TCP MTU Probing
0 = disabled
1 = enabled when a black hole router is detected
2 = always enabled
# Enable TCP MTU probing to deal with black hole routers:
echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing
echo 1024 > /proc/sys/net/ipv4/tcp_base_mss
Je vais essayer de faire un test de mise en place d'un tunnel OpenVPN full IPV6 dans la semaine + retester la freebox en bridge sur mon ERLite avec mtu 1472 et avec MTU 1500 + PMTU Discovery
Didier
-
ai-je raté quelque chose ???
Un scan exhaustif en 91.160.x.y ne détecte aucune freebox.
J'ai vérifié qu'il y a des utilisateurs en ip v6 ZMD dont la conversion en v4 s'effectue sur la plage 1/4 des ports (celle qui répond au ping)
le ping serait-il bloqué par free en 91.160 ?
Merci
-
Laquelle des 4 boxes derrière l'IPv4 doit répondre ?
Ou alors est-ce que c'est l'infra 4rd qui doit répondre ?
Dans les deux cas ça n'avance pas à grand chose que ça réponde, de mon point de vue !
-
En plus, l'IPv4 est transportée dans une trame IPv6 (4rd). Vivien avait vu qu'un traceroute sur ces adresses s'arrêtait à l'entrée du tunnel, un routeur à Courbevoie. Donc un scan sur les adresses 91.160 ne mène à rien.
-
OK
-
un routeur à Courbevoie
Bezons plutôt ?
-
Bezons plutôt ?
Il me semblait que Vivien avait parlé de Courbevoie, et je viens de vérifier, c'est le cas :
Le dernier routeur est "cbv-crs8-1.intf.routers.proxad.net" donc un gros Cisco CRS localisé sur Courbevoie (92).
https://lafibre.info/free-10g-epon/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/msg283323/#msg283323
-
un traceroute vers une ip en ZMD :
L:\>tracert 91.160.5.1
Détermination de l'itinéraire vers 91-160-5-1.subs.proxad.net [91.160.5.1] avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms Freebox_Serge.31_LAN [192.168.0.254]
2 5 ms 5 ms 7 ms sto31-1_gw [78.213.148.254]
3 21 ms 12 ms 6 ms toulouse-x-routers [213.228.9.254]
4 7 ms 21 ms 14 ms toulouse-crs8-2-be1006.intf.routers.proxad.net [194.149.160.69]
5 17 ms 25 ms 22 ms bzn-crs16-2-be1119.intf.routers.proxad.net [194.149.163.25]
6 16 ms 36 ms 16 ms bzn-crs16-2-be1005.routers.proxad.net [78.254.249.77]
7 * * * Délai d'attente de la demande dépassé.
le dernier vu est bzn-crs16-2-be1005.routers.proxad.net ... ce qui pourrait expliquer cette différence.
D'autres traceroute pour vérifier ?
-
Depuis une Bbox en Gironde :
My traceroute [v0.85]
kirino (0.0.0.0) Mon Mar 21 19:37:09 2016
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.254 0.0% 100 0.4 0.4 0.4 0.8 0.0
2. bft33-h01-176-146-77-126.dsl.sta.abo.bbox.fr 0.0% 100 21.9 24.2 20.5 72.4 6.5
3. 51.la63.bsr01-bdx.net.bbox.fr 0.0% 100 21.8 36.9 21.0 834.8 102.7
4. be65.cbr01-poi.net.bbox.fr 0.0% 100 27.8 26.3 23.9 29.1 1.1
5. be5.cbr01-ntr.net.bbox.fr 0.0% 100 30.4 33.1 27.9 167.3 13.8
6. la42.rpt06-th2.net.bbox.fr 82.8% 100 29.3 28.9 28.3 29.7 0.0
7. ???
8. p11-crs16-1-be1001.intf.routers.proxad.net 0.0% 100 32.0 31.5 28.7 72.0 4.2
9. cbv-crs8-1.intf.routers.proxad.net 0.0% 100 29.9 29.7 28.8 52.9 2.3
10. ???
On peut supposer que le hop n°10 ici c'est l'infra 4rd, qui ne réponds pas au ping, et qu'elle est accessible directement depuis différents routeurs sur le réseau de Free ? Ce qui explique comment le dernier hop que tu vois est à Bezons, et moi à Courbevoie.
-
Je suis sur le réseau Free, et j'ai :
$ mtr -rwc100 91.160.5.1
Start: Mon Mar 21 19:39:10 2016
HOST: ubuntu-srv Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.0.254 0.0% 100 26.9 18.4 1.8 72.1 18.9
2.|-- arp91-4-78-235-182-254.fbx.proxad.net 0.0% 100 65.1 32.0 6.5 91.1 23.5
3.|-- 213.228.23.254 0.0% 100 18.6 25.4 7.1 77.9 20.1
4.|-- p11-crs16-1-be1114.intf.routers.proxad.net 0.0% 100 28.5 32.4 8.5 85.9 21.7
5.|-- cbv-crs8-1.intf.routers.proxad.net 0.0% 100 63.2 29.8 8.0 71.5 19.5
6.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
$ traceroute 91.160.5.1
traceroute to 91.160.5.1 (91.160.5.1), 30 hops max, 60 byte packets
1 192.168.0.254 (192.168.0.254) 30.677 ms 30.680 ms 30.668 ms
2 arp91-4-78-235-182-254.fbx.proxad.net (78.235.182.254) 30.661 ms 30.653 ms 30.596 ms
3 213.228.23.254 (213.228.23.254) 30.543 ms 30.507 ms 30.473 ms
4 p11-crs16-1-be1114.intf.routers.proxad.net (194.149.162.145) 45.696 ms 45.638 ms 45.629 ms
5 cbv-crs8-1.intf.routers.proxad.net (78.254.249.102) 30.332 ms 30.526 ms 30.488 ms
6 * * *
Dans les deux cas, j'arrive jusqu'au routeur à Courbevoie.
-
Chez moi l'IP est même pas routée, wtf
Target Name: 91-160-5-1.subs.proxad.net
IP: 91.160.5.1
Date/Time: 21/03/2016 19:46:11 to 21/03/2016 19:46:50
Hop Sent Err PL% Min Max Avg Host Name / [IP]
1 11 0 0,0 0 0 0 rb1100.gw [172.16.0.254]
2 11 0 0,0 0 2 0 94cpy1-nro-1.nro.gaoland.net [109.24.76.32]
3 11 0 0,0 1 154 26 37.142.24.109.rev.sfr.net [109.24.142.37]
4 10 10 100,0 0 0 0 [-]
[...]
Destination not reached in 35 hops
-
Parce que les routes vers ces adresses n'ont pas été annoncées sur les routeurs SFR ?
-
Si ?
nico@debian2-vm:~$ mtr -rwc10 91.160.5.1
Start: Mon Mar 21 20:18:51 2016
HOST: debian2-vm Loss% Snt Last Avg Best Wrst StDev
1.|-- box 0.0% 10 0.5 0.5 0.4 0.6 0.0
2.|-- 75tip1-nro-1.nro.gaoland.net 0.0% 10 1.7 2.5 0.8 4.9 1.1
3.|-- 21.48.20.93.rev.sfr.net 0.0% 10 1.7 3.3 1.4 6.1 1.5
4.|-- 90.116.3.109.rev.sfr.net 0.0% 10 4.0 5.0 3.1 7.6 1.8
5.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6.|-- p11-crs16-1-be1000.intf.routers.proxad.net 0.0% 10 9.4 6.2 4.7 9.4 1.8
7.|-- cbv-crs8-1.intf.routers.proxad.net 0.0% 10 5.1 4.5 2.1 7.3 1.4
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
Mais j'en conviens, un traceroute ne fonctionne pas.
-
En fait ça marche depuis une autre machine donc ça vient pas de la connexion, vraiment bizarre car j'arrive bien sur le réseau de SFR. Sinon la fin du traceroute est identique à celui de Nico.
-
je suis le seul à terminer sur bzn-crs16-2-be1005.routers.proxad.net [78.254.249.77] ?
depuis une connexion dégroupée chez Free.
-
je suis le seul à terminer sur bzn-crs16-2-be1005.routers.proxad.net [78.254.249.77] ?
Testé depuis plusieurs connexions dégroupées Free et je tombe sur cbv ; idem depuis dédibox.
Par contre depuis serveur dédié chez OVH je tombe aussi sur bzn
Détermination de l'itinéraire vers 91-160-5-1.subs.proxad.net [91.160.5.1]
avec un maximum de 30 sauts :
1 1 ms 1 ms 1 ms rbx1-3a-a9.fr.eu [91.121.122.252]
2 1 ms 3 ms 2 ms be11-149.rbx-g2-a9.fr.eu [37.187.231.67]
3 4 ms 4 ms 4 ms be99-1181.gsw-1-a9.fr.eu [213.251.130.55]
4 * * * Délai d'attente de la demande dépassé.
5 11 ms 7 ms 7 ms bzn-crs16-2-be1013.intf.routers.proxad.net [194.
149.163.157]
6 4 ms 4 ms 4 ms bzn-crs16-2-be1005.routers.proxad.net [78.254.24
9.77]
7 * * * Délai d'attente de la demande dépassé.
-
je me sens moins seul :P
-
Sur une ligne non dégroupée Free vers 91.160.5.1 :
1 192.168.254.254 (192.168.254.254) 20.148 ms 19.728 ms 20.673 ms
2 bzn-6k-5-v201.routers.proxad.net (212.27.55.126) 21.188 ms * *
3 p11-9k-1-be1026.intf.routers.proxad.net (212.27.57.126) 21.640 ms 21.138 ms 21.666 ms
4 p11-crs16-1-be1008.intf.routers.proxad.net (194.149.163.53) 22.164 ms 23.959 ms 23.357 ms
5 cbv-crs8-1.intf.routers.proxad.net (78.254.249.102) 20.722 ms 21.390 ms 20.514 ms
6 * * *
7 * * *
8 * * *
Pas beaucoup de sauts et je tombe sur cbv et non bzn. Je fais le test directement depuis mon routeur, le premier saut c'est le DSLAM.
-
L'IP dédiée, Rani a dit que l'option serait gratuite, et que l'on pourrait même avoir plusieurs IP (option payante). Mais on attend toujours sa réponse sur la date de disponibilité de l'option...
Pour moi, en ZMD, c'est toujours en beta-test. Mais chez Free, on l'a souvent vu (freebox v6, 4K etc...), on peut être en beta-test et en même temps en étape de commercialisation. Il vaut mieux attendre que les soucis soient réglés avant de souscrire...
P.S : au fait, tu as quel range de ports ?
Je suis désolé si cela a déjà été dit sur ce thread, mais est ce que la procédure pour demander une IP dédiée est déjà existante et si oui, quelle est t'elle ?
-
La réponse est, non, elle n'existe pas encore.
-
La réponse est, non, elle n'existe pas encore.
Merci pour ta réponse rapide
Ma migration vers la fibre est prévue pour le 21 avril et, pas de bol, ma plage de port est prévue sur 49152-65535 ...
je pourrais m'y faire si besoin, mais une dédiée serait quand même plus cool ...
-
Comment as-tu trouvé ta plage de ports avant d'être raccordé ?
-
Tu peux voir ton adresse IP et ta plage de port avant d'avoir reçu ta box, dès que ton espace client est activé, dans Ma Freebox > Afficher mon adresse IP.
-
Oui, le SI de Free s'améliore dans le support des ZMDs. Ces informations ne figuraient pas avant. D'autres ont eu pendant quelque temps leur ancienne IP xDSL.
On attend aussi la concrétisation de la promesse de Rani sur l'IP complète...
-
D'autres ont eu pendant quelque temps leur ancienne IP xDSL.
Sur une connexion fibre ? :o
-
Non, l'interface était juste pas mise à jour.
-
Bonjour,
Pour ma part, je suis client Free (Fibre) et je suis passé sur ces fameuses IP partagées.
On m'a assigné les ports de 0 à 16383, et ils sont en effet utilisables par les logiciels qui initient des connexions vers l'extérieur.
Mais sauf erreur de ma part, seul le port 80 est joignable depuis l'extérieur.
j'ai en effet essayé de monter un serveur IIS, et ma page web n'est accessible que quand IIS est bindé sur le port 80.
Cela ne semble pas fonctionner avec les autres ports.
Probablement à cause de ça, ma femtocell Orange, branchée en Ethernet sur ma Freebox, ne fonctionne plus sur la ligne Fibre.
Elle nécessite l'ouverture de différents ports (500 UDP, 4500 UDP...) et je pense que l'IP partagée bloque cette fonctionnalité.
Si quelqu'un a une solution (autre que IPv6 car la femtocell n'est pas compatible), je suis preneur. Autrement, j'envisage de changer d'opérateur.
Pour la hotline Free, tout est normal, du moment que la navigation internet fonctionne....
Cordialement,
-
Autrement, j'envisage de changer d'opérateur.
Mobile ou fixe ?
-
Fixe je suppose.
Par contre je ne comprends pas trop, tu testes quoi exactement ? Ouvrir un port P sur la Freebox et le rediriger vers ton serveur web qui est configuré pour écouter sur ce fameux port P ?
-
Oui pardon, je n'ai pas été très clair.
Si je ne règle pas mon problème de Femtocell, je choisirais un autre opérateur Internet.
@Underground78 : c'est exactement ça. la Freebox est configurée pour rediriger les paquets venant de l'extérieur vers mon serveur IIS. Lorsque tout est configuré avec le port 80, ça fonctionne bien. Mais si je prend le port 81 par exemple, alors le site n'est accessible que depuis le réseau local. Je ne crois pas m'être trompé dans une configuration quelconque.
Mon problème de fond est que ma femtocell Orange n'arrive pas à se connecter aux serveurs Orange et c'est très probablement lié à cette IP partagée. Durant une semaine, j'avais les deux lignes ADSL et FIBRE en même temps, et la femtocell fonctionnait correctement en ADSL (IP complète) mais ne fonctionnait pas en FIBRE (IP partagée).
Je crois que la solution choisie par Free rend incompatible certains équipements.
-
C'est quand même super bizarre, il me semble que des abonnés en ZMD arrivaient bien à rediriger les ports qui leur appartiennent. Il faudrait creuser la chose, si ce que tu dis se confirme, j'aurais tendance à penser que ce n'est pas le comportement attendu.
-
Peux-tu poster une capture écran des redirections de ports que tu as paramétré sur la freebox serveur ?
-
C'est quand même super bizarre, il me semble que des abonnés en ZMD arrivaient bien à rediriger les ports qui leur appartiennent. Il faudrait creuser la chose, si ce que tu dis se confirme, j'aurais tendance à penser que ce n'est pas le comportement attendu.
Je confirme.
Pas de soucis de mon coté pour rediriger ma super plage de port (49000 => 65000) vers mes machines
-
Cela ne résout pas le problème de la femtocell tu me diras :/
-
Tes tests sont depuis ton LAN ou depuis l'extérieur (pb loopback)?
-
Dommage que rani ne passe plus par ici sinon ça serait un bon cas pratique à lui soumettre.
-
Bonjour,
Merci à vous tous pour votre implication !
Alors suite au commentaire de Tindav, j'ai double checké. Et au final, je me suis aperçu que c'était le pare feu windows qui me jouait des tours (port 80 ouvert, port 81 fermé, mais 81 en IPv6 fonctionne.... ?).
Donc au final l'erreur venait de moi, les ports sont bien accessibles depuis l'extérieur.
Du coup pour la femtocell, je vais chercher un peu car ça ne doit pas être lié à l'IP partagée, il doit y avoir une autre explication.
J'ai ouvert les ports UDP-4500, UDP-500, UDP-2746, TCP/UDP-123, mais peut être que ce n'est pas suffisant.
Merci à tous, vous m'avez bien aidé en tout cas.
-
Après avoir regardé en détails les protocols/ports utilisés par la femtocell, je vois qu'elle créée un tunnel IpSec et qu'elle a besoin des ports suivants :
IP-50 (ESP)
IP-51 (AH)
IP-57 (SKIP)
UDP-4500
UDP-500
UDP-2746
TCP/UDP-123(NTP)
Est-ce que la création du tunnel IpSec pourrait être incompatible avec l'IP mutualisée ?
Je ne connais pas du tout et la littérature sur le sujet est assez complexe :(
-
C'est tout à fait possible également.
-
Je pense qu'il y a bien une incompatibilité entre IpSec et les IP partagées de Free :(
RFC 6346: The Address plus Port (A+P) Approach to the IPv4 Address Shortage
5.3.4. Limitations of the A+P Approach
[...]
Another problem that is common to all NATs is coexistence with IPsec.
In fact, a NAT that also translates port numbers prevents the
Authentication Header (AH) and Encapsulating Security Payload (ESP)
from functioning properly, both in tunnel and in transport mode. In
this respect, we stress that, since an A+P subsystem exhibits the
same external behavior as a NAT, well-known workarounds (such as
[RFC3715]) can be employed.
-
Ça serait le moment d'invoquer Rani pour voir ce qu'il a proposé (au pire dans combien de temps arrive l'option "IP non partagée").
-
Ça serait le moment d'invoquer Rani pour voir ce qu'il a proposé (au pire dans combien de temps arrive l'option "IP non partagée").
Y'a rien à corriger. Orange doit passer ses femto sur IPv6, ou l'abonné doit prendre un FAI qui offre une connectivité complète en IPv4 sans ce mécanisme. (en attendant la fameuse option de Free ..?)
-
J'ai pas dit "corriger", j'ai dit "proposer". Comprendre que je pense qu'il serait intéressant d'avoir des nouvelles de la fameuse option par la personne qui l'a annoncée.
-
Cela fait près de deux mois et demi qu'il a dit que cette option allait arriver "bientôt" (c''était le 13 Février).
https://lafibre.info/free-10g-epon/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/msg307247/#msg307247
-
Ça serait le moment d'invoquer Rani pour voir ce qu'il a proposé (au pire dans combien de temps arrive l'option "IP non partagée").
A force je sais plus si on connait vraiment l'intérêt officiel de la chose, du "radiniel" ?
-
Après avoir regardé en détails les protocols/ports utilisés par la femtocell, je vois qu'elle créée un tunnel IpSec et qu'elle a besoin des ports suivants :
IP-50 (ESP)
IP-51 (AH)
IP-57 (SKIP)
IP-x ne désigne pas un numéro de port!
-
Oui, ce sont des numéros de protocole, comme ICMP peut en être un, mais il faut aussi expliquer...
Voir par exemple (en anglais) :
http://www.linuxquestions.org/questions/linux-networking-3/what-is-protocol-50-a-375085/
https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
-
Oui, ce sont des numéros de protocole, comme ICMP peut en être un, mais il faut aussi expliquer...
Voir par exemple (en anglais) :
http://www.linuxquestions.org/questions/linux-networking-3/what-is-protocol-50-a-375085/
https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
On ne peut donc pas les diviser comme on divise les ports.
-
Cela fait près de deux mois et demi qu'il a dit que cette option allait arriver "bientôt" (c''était le 13 Février).
quand on convertit le bientot en échelle temporelle Free ca peut donner bien des mois (en années)
-
Bon, l'échelle temporelle de Free du "bientôt", c'est effectivement des mois, voire plus d'une année. Mais par expérience (le cas de la fibre est peut-être moins optimiste...), cela finit pas arriver. Alors on va espérer et patienter (facile pour moi, je suis en zone AMII Orange, où le déploiement devait commencer en 2015, mais toujours pas de fibre...).
-
Cela fait près de deux mois et demi qu'il a dit que cette option allait arriver "bientôt" (c''était le 13 Février).
https://lafibre.info/free-10g-epon/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/msg307247/#msg307247
Ce sera dispo à partir de la semaine prochaine.
-
Merci Rani pour l'info. Enfin ! Cela manquait à l'offre en ZMD.
-
Ce sera dispo à partir de la semaine prochaine.
Merci Rani, c'est cool de nous tenir au courant 8)
-
Merci Rani pour l'info. Enfin ! Cela manquait à l'offre en ZMD.
Ce qui manque aussi c'est l'offre en ZMD SFR et ce sera pas la semaine prochaine ;) hein Rani :)
-
C'est sûr que pour les ZMDs SFR, cela risque de ne pas être la semaine prochaine. Il faudra déjà que Free décide d'une solution pour loger ses switchs ZMD, puis tirer ses fibres jusqu'aux PM.... Pourra-t-il comme dans les zones Orange utiliser les NRA/NROs Orange ? Utiliser ceux de SFR ? Installer ses propres NROs ?
-
Bonne nouvelle en tout cas, peut-être que ça va arriver avec une certaine normalisation de la communication autour des ZMD (notamment sur le site de l'assistance Free) ?
-
Ce sera dispo à partir de la semaine prochaine.
Merci pour l'info :) En ZTD aussi possibilité d'avoir plusieurs IP ?
-
Merci pour l'info :) En ZTD aussi possibilité d'avoir plusieurs IP ?
A mon avis cela va ensemble. Le mécanisme est le meme, donc si l'un existe, lautre est forcèment pas loin
-
Ce sera dispo à partir de la semaine prochaine.
C'est bien de dire qu'une option seras disponible ( mème si c'est cacher dans un forum )
Ce serais encore mieux ce serais d'avoir une carte de reploiement ZMD FTTH avec des dates ( on est pas au trimestre près ! )
exemple a Vannes (56) je ne voit toujours pas de FttH en vue (aucune date ?) ( ni de 4G qui couvre mon quartier de la madeleine - AV de la marne )
Orange le fait bien ? pourquoi pas FREE ?
Je n'ose pas croire les rumeurs qui dit que les déploiements FREE sont fait au "FEELING" , et qu'il n'y a aucun plan réel en vue ??
-
Surtout qu'ici on parle de la technologie 4rd utilisée par Free en ZMD (et probablement dans les nouvelles ZTD) pour faire de l'IPv4 par dessus IPv6. :)
-
Ce sera dispo à partir de la semaine prochaine.
Je me met à rêver en lisant ton annonce Rani !
Est-ce que je vais pouvoir ressortir de son placard mon Ubiquity ERLite, et pouvoir profiter d'un uplink sans setter une MTU à 1472 ? (avec comme conséquence une limitation des débits drastiques avec un OpenVPN par exemple + instabilités).
Est-ce que le fait de prendre l'option "IP Fixe" nous permet de sortir de cette architecture avec NAT + MTU abusive ou en fait on reste dans cette infra, avec "juste" le confort de toutes les plages de port 0-65535 disponibles ?
Cordialement,
Didier
-
Je ne pense pas que la MTU change puisque la technologique utilisée reste la même. Par contre je croyais que Free utilisait des "jumbo frames" justement pour conserver la MTU identique ?
Edit : J'ai retrouvé le message en question : https://lafibre.info/free-10g-epon/port-443-non-accessible-sur-free-ftth/msg314899/#msg314899
-
Je me met à rêver en lisant ton annonce Rani !
Est-ce que je vais pouvoir ressortir de son placard mon Ubiquity ERLite, et pouvoir profiter d'un uplink sans setter une MTU à 1472 ? (avec comme conséquence une limitation des débits drastiques avec un OpenVPN par exemple + instabilités).
Est-ce que le fait de prendre l'option "IP Fixe" nous permet de sortir de cette architecture avec NAT + MTU abusive ou en fait on reste dans cette infra, avec "juste" le confort de toutes les plages de port 0-65535 disponibles ?
Cordialement,
Didier
c'est la meme techno et le MTU est a 1500 grace au jumbo frames.
apres en quoi est-ce une architecture abusive ? autant le partage d'une IPv4 pour 4 est discutable, autant le 4rd avec une IP full ne l'est pas (si le débit est maximum en IPv4 bien sur).
-
c'est la meme techno et le MTU est a 1500 grace au jumbo frames.
apres en quoi est-ce une architecture abusive ? autant le partage d'une IPv4 pour 4 est discutable, autant le 4rd avec une IP full ne l'est pas (si le débit est maximum en IPv4 bien sur).
En fait, je n'avais pas vu l'activité depuis courant Février :
En ZMD, la mtu es à 1500 que ça soit en v4 ou en v6. On supporte les jumbo.
Rani :
"Par contre, y a un soucis (lire bug) sur certains ONU qui prennent pas correctement leur conf pour
accepter les jumbo qui est apparu suite à une modif mi-février (ce qui pose donc des pbs en v4).
Y a eu une correction la nuit dernière mais on voit encore quelques cas => on va voir avec le constructeur."
Je confirme que depuis début Mars je n'ai pas retenté de passer la MTU a 1500, mais qu'après de nombreux tests la seule façon d'avoir une connectivité (ping, OpenVPN, traceroute, etc), c'était bel et bien de passer la MTU a 1472.
Si le "bug" est corrigé, je vais m'empresser de faire un petit test ce soir !
Du coup, merci pour l'information !
Cordialement,
Didier
-
Et merci d'avance pour le retour ;)
-
Pour ceux qui veulent continuer le HS, sur le dėploiement, la propriété ou la location, c'est là...
https://lafibre.info/bistro-sujet-libre/ftth-zmd-free-ferait-du-4rd-ipv4-portee-par-ipv6-et-nat-sur-le-reseau/
Prochain(s) message(s) hors sujet 4rd, c'est direct poubelle.
-
Clubic a fait un article (http://www.clubic.com/connexion-internet/fai-free-box-freebox/actualite-808988-freebox-ipv4-dediee-4rd.html) sur l'option IPv4 dédiée en citant lafibre.info :)
-
Ce sera dispo à partir de la semaine prochaine.
Bon, on a raté la mise en place de l'option ou elle est en retard ?
-
Bonjour,
Idem... Toujours a attendre et à surveiller l'espace client.
J'attends cette possibilité avec impatience car je suis pénalisé avec cette histoire de partage des ports.
-
Bon, on a raté la mise en place de l'option ou elle est en retard ?
La semaine free ? 8)
-
Le 8 juin c'était encore un "work in progress" d'après un corp Free sur les newsgroups (http://www.journaldufreenaute.fr/outils/nspy.php?post=44940).
-
Avec Free, il faut apprendre à être patient et à ne pas se fier aux ETA annoncées ;D
-
On dirait un adolescent quand on l'appelle pour manger, c'est rigolo (et je sais de quoi je parle !)
-
On dirait un adolescent quand on l'appelle pour manger, c'est rigolo (et je sais de quoi je parle !)
Ah ah excellent
-
Ce sera dispo à partir de la semaine prochaine.
Rani, on n'a rien vu cette semaine. Il y a du retard ?
-
Rani, on n'a rien vu cette semaine. Il y a du retard ?
Il viendra le confirmer demain (soit le 14/07/2016)... Et oui, chez Free, le temps a une autre valeur que celle de la rotation de la terre sur son axe...
-
En fait Free se déplace à grande vitesse par rapport à nous, mais alors très très grande la vitesse...
-
On dirait un adolescent quand on l'appelle pour manger, c'est rigolo (et je sais de quoi je parle !)
Dixit l'adolescent hein... ;D
-
Si c'est en retard de seulement une semaine pour des tests & MeP ça va :D ! C'est pas comme la V7 qui est en retard de X
semaines mois années
-
En effet, 1 semaine, c'est rien... Si seulement j'avais le choix entre mon IP complète actuelle et la fibre... ::)
-
Dixit l'adolescent hein... ;D
Ben c'est pour ça que je sais de quoi je parle :-)
-
En effet, 1 semaine, c'est rien... Si seulement j'avais le choix entre mon IP complète actuelle et la fibre... ::)
Il est certain que la Fibre permet des utilisations confortables et avancées.
Cependant lorsque cette dernière te pénalise cela n'est pas très agréable!
Dans mon cas, je ne peux pas accéder à mes serveurs distants (hébergés chez OVH) !
Mais j'ai solutionné provisoirement le truc en passant par un VPN pour me connecter.
il aura aussi fallu que je modifie toutes mes config pour l'accès à distance à mes caméras, à la Freebox et le plus chiant c'est mon serveur de jeux (et de DATA)
Bref... même si la fibre assure une qualité de connexion indéniable, le partage de ports te handicape fortement lorsque tu as une utilisation un peu avancé de ton accès web.
Ce qui, il faut l'avouer, est vraiment un comble!
Avoir la fibre et ne pas pouvoir accéder à des serveurs (sans passer par un VPN) est juste hallucinant!
Est-il utile de rappeler que le principe même d'internet c'est d’accéder rapidement et simplement à des serveurs ?
Seuls ceux qui téléchargent comme des "porcs" se réjouiront d'un tel système puisque la loi autorise la HADOPI à demander des identités en rapport avec des adresses IP mais le texte ne prévoit rien pour les ports.
Dans un tel cas la HADOPI devrait donc recevoir de 1 à 4 noms pour une même A.IP
-
Dans mon cas, je ne peux pas accéder à mes serveurs distants (hébergés chez OVH) !
Ça c'est bizarre, comment y accèdes-tu ?
-
Ça c'est bizarre, comment y accèdes-tu ?
AH oui pardon... j'ai oublié de préciser.
Impossible d'accéder à mes serveurs via le FTP (port 21)
Je passe donc par un VPN
-
1/ FTP en 2016 ? Beurk, SFTP rulez !
2/ Je suis pas étonné, le FTP est un truc très bizarre avec le NAT et ce genre de trucs, je me souviens d'abonnés K-Net qui ont eu des soucis avec ça.
-
Seuls ceux qui téléchargent comme des "porcs" se réjouiront d'un tel système puisque la loi autorise la HADOPI à demander des identités en rapport avec des adresses IP mais le texte ne prévoit rien pour les ports.
Ils ne se réjouiront de rien puisque la Hadopi n'est pas un organisme à but répressif et est loin d'agir de manière effective comme un organisme de répression. Et la substitution de cet identifiant de par l'utilisation d'un réseau privé virtuel est plus triviale que de se soucier de ces considérations techniques.
-
1/ FTP en 2016 ? Beurk, SFTP rulez !
Comme beaucoup de choses, ça dépend du besoin :)
Pour un serveur hébergeant des drivers par exemple .. Le FTP est loin d'être mort, et ce n'est pas forcèment une mauvaise chose. C'est ultra simple, basique, et ca marche bien.
-
Impossible d'accéder à mes serveurs via le FTP (port 21)
Il suffit de régler correctement le mode passif/actif et ça devrait refonctionner.
-
Il suffit de régler correctement le mode passif/actif et ça devrait refonctionner.
J'ai déjà essayer, sans succès (idem pour le SFTP)
-
ca ne marche pas sur ftp://1.testdebit.info ?
-
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.
-
[/quote]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.
-
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.
-
Je teste ce soir...
Cependant, à partir du moment ou le client à la plage "0/16383" il ne devrait rencontrer de pb
-
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).
-
Je ne comprends pas de quel problème tu veux parler!
-
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
-
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 ;-)
-
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
-
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.
-
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.
-
Bonjour alain_p,
je pense que je me suis mal exprimé, je n'écris pas en tant que client FREE ayant des problèmes, mais en tant que service informatique d'une banque ayant des utilisateurs chez FREE, qui eux présentent un problème. La majorité des utilisateurs se situe en région parisienne en ZMD.
Ayant parcouru le thread, j'ai effectivement lu les informations selon lesquelles le MTU ne devrait pas être un problème. Cependant j'ai précisé notre configuration pour écarter ce sujet.
J'ai lu tous ce qu'il y avait a lire sur les technos mentionnées dans ce thread concernant la configuration FREE en ZMD.
Si je me suis décidé a écrire ici, c'est essentiellement parce qu'il est impossible de contacter FREE si on n'est pas client. J'ai essayé en vain.
Puisque certains ici semblent avoir des contacts autres, je me suis décidé à poster.
Je finirai par décrire rapidement la configuration utilisée :
anyconnect (le client vpn cisco) utilise 2 tunnels : un TCP-443 et un UDP-443.
le TCP est monté en premier, et lui fonctionne bien, puisque TCP gère les pertes de paquets.
l'UDP est ensuite établi (avec les infos du premier) et une tentative de détermination du MTU du tunnel est lancée, avec le principe du Keep-alive (envoi hello, réponse ok), de taille, qui décrèmente, jusqu'a obtenir une réponse.
Le problème est donc : dû aux pertes de paquets, les keep-alive de détermination de MTU, sont perdus. Le client considère que le MTU est trop bas, et il relance la négociation indéfiniment. le tunnel est donc inutilisable.
Vous me direz : désactive l'UDP, comme ça le tunnel TCP sera utilisé et tout ira bien. C'est vrai. mais ce n'est pas possible, puisque nos 2500 utilisateurs ne sont pas tous chez free en fibre en zmd, et que dans tous les autres cas le tunnel UDP fonctionne. Le tunnel UDP est nécessaire pour des questions de performance des applications de TOIP déployées sur les postes.
Bref, heureusement que le full stack ipv4 résoud le problème, sinon nous aurions été obligé de spécifier au support utilisateur de conseiller aux personnes impactées de changer d'opérateur.
Malgré la solution trouvée, je suis interressé pour comprendre ce qu'il se passe.
-
Bonjour Buzzer,
Merci pour les précisions. En effet, il manquait certaines informations pour que je comprenne bien la situation. De ce que j'avais lu, vous n'étiez effectivement pas forcèment chez Free, mais vous auriez pu être une entreprise dont les employés se connectaient à distance à leur siège en employant ce moyen, et donc dans une région donnée.
Est-ce que vous auriez la possibilité d'utiliser l'IPv6 dans votre tunnel Cisco anyconnect ? C'est en effet l'IPv6 qui est utilisée par défaut en 4rd en ZMD. Je pensais aussi à la possibilité de faire un ping sur l'adresse de la box du client en IPv6, pour voir s'il y a des pertes de paquets, et éventuellement un traceroute en IPv6, pour voir à quel niveau se situerait le problème.
En ZMD, on ne peut pas pinger l'adresse IPv4 du client, évidemment quand elle est partagée, mais il me semble aussi quand elle est "full stack".
Est-ce que ce serait par exemple l'interconnexion qui pourrait poser problème ?
-
Il est possible de pinger l'adresse IPv4 "full-stack".
PS : A mon avis il est possible d'avoir une réponse en contactant officiellement Free en tant que service technique de la banque dont les abonnés rencontrent des problèmes.
-
Cela me rappelle qu'il y aussi la mailing list FRnOG sur laquelle certains officiels Free participent.
Merci sinon pour la précision, l'adresse "full stack" est donc pingable, mais ne pose pas de problème...
-
oui FRnOG me semble la bonne piste et si on sort d'un forum grand public pour aller vers un truc pro/expert cela fera peut-être réagir Free...
c'est en plus la 'raison d’être' de FRnOG. C'est par la: http://www.frnog.org/?lang=fr (oui c'est un peu vieillot, a l'ancienne sous forme de mailing-list plutot qu'un site web 2.0 mais bon une fois de plus le dicton sur les cordonniers s’avère vrai ::)).
-
Sinon il y a toujours l'option d'envoyer un MP à Rani Assaf sur le forum.
-
Bonjour,
merci pour vos infos.
Je me suis inscrit sur frong .... on verra bien ce quel se passe sur la mailing list.
Je n'ai pas la possibilité d'activé l'IPv6, car nous avons une infrastructure mutualisée avec le groupe et l'opérateur en place ne propose pas l'IPv6.
Le groupe n'a de toute façon pas de plan pour l'IPv6 ... ce que j'essaie de faire bouger.
-
oui FRnOG me semble la bonne piste et si on sort d'un forum grand public pour aller vers un truc pro/expert cela fera peut-être réagir Free...
Ce forum est quand même pas mal consulté, et suivi. Si on commence à dire qu'il y a des problèmes avec l'IP partagée, et qu'il vaut prendre l'IP "Full stack", cela peut faire réagir. Car l'idée avec l'IP partagée, c'était quand même de faire des économies d'IPv4. Si tout le monde se met à prendre l'option, l'objectif sera un peu raté, et la publicité pas très bonne...
Il est clair que le nombre d'abonnés ZMD en 4rd augmente rapidement, et que les problèmes éventuels avec cette architecture vont être de plus en plus apparents.
-
Bonjour,
Je suis sur une infra DSLAM IPV6 FULL.
je suis arrivé avec LEDE/OpenWRT et un modem VDSL en Bridge à avoir l'IPV6 avec un tunnel 6to4 et j'ai mis mes IPV4 en dur.
Cependant je n'arrive toujours pas à avoir internet. Mais c'est quand même une avancée.
J'ai aussi cloné l'@ MAC.
La piste me semble intéressante.
-
Y'a rien de bon là.
L'IPv6 est une IPv6 6to4, donc pas bon.
Et l'IPv4 est portée via un tunnel 4Rd dans IPv6. Donc aucune chance de l'avoir comme ça.
Pour l'instant, personne n'a réussi a Bypass la Freebox en nouvelle archi.
-
Bonjour!
Enfin quelqu'un de volontaire pour faire la connection sur un DSLAMv6.
T'es en IP full stack? Si non, cela peut être la source du problème mais une commande iptables qui va bien devrait résoudre cela.
Quand tu tcpdump un ping depuis le LAN vers le net, tu vois bien le ping sortir encapsulé dans l'IPv6 avec la bonne IPv4 source (en gros le masquerading marche bien)?
Edit: j'avais pas vu le 6to4. Faudrait du 4to6 plutôt. C'est vraiment un DSLAMv6 ou c'est juste pour avoir l'IPv6 donné par le tunnel 6rd (un DSLAMv4)?
-
Bonjour,
C'est bien un DSLAM IPV6 et avec IPV6 activé.
Oui je suis en FullStack. Après en 6to4 LEDE trouve bien une IPV6 (DHCP) genre Tunnel avec une Gateway.
Autre observation, si je mets autre chose que mon IPV4 cela ne fonctionne pas.
Je vais faire de la copie de port et du wireshark pour voir ce qui passe entre le routeur et le modem en bridge.
Il se peut qu'il y ai quelque chose comme orange du genre un DHCP avec des paramètres ....
Pour Hugues, personne n'a réussi, mais y'a pas grand monde non plus qui poste des tentatives avec des config openwrt/LEDE, donc pas facile de réussir !
Ci dessous une capture WS.
-
Ouais non rien de choquant.
On voit bien le tunnel IPIP utilisé pour encapsuler v4 dans v6.
Du coup quel est le souci ? Suffit de trouver les IPs d'interco, mettre ton préfixe sur le LAN et ça passe, non ?
On peut même tenter un tunnel IPIP pour avoir de la v4 ;)
Par contre, DHCP en 6to4... T'as pas compris.
6To4, c'est un Tunnel, par dessus IPv4, qui utilise ton IPv4 publique pour mapper un préfixe IPv6, c'est pour ça que tu crois avoir une IP en 6to4. C'est de l'autoconf, pas du DHCP.
Pour moi, soit c'est du DHCPv6-PD sur un VLAN, soit c'est en statique avec conf TR-069 ou équivalent chez Free.
Du coup, suffit de sniffer, d'analyser les premières requètes, et ca devrait se clarifier :)
-
Je me demande si en VDSL ils utilisent aussi les jumbo frames pour garder une MTU à 1500 sur l'IPv4.
-
Je pense oui, en vrai, c'est pas vraiment du Jumbo vu l'encapsulation...
-
Non en VDSL la MTU diffusées par le RA est de 1480. Donc pas de jumbo. D'ailleurs je ne sais pas si le chipset de la v5 supporte des frames > 1520 (L2 inclus).
-
Je vois pas le rapport, on parle de l’infra v6 only là, il n’y aura pas de MTU à 1480 pour v6 dans tous les cas puisqu’elle n’est pas encapsulée.
C’est assez rare les chips qui ne gèrent pas une MTU >1500, sans parler de Jumbo.
-
Bien vu... je suis fatigué pffff
Je ne sais pas si la MTU reste 1500 pour IPv4.
-
Yep, on verra :)
Moi je suis assez optimiste, les chips supportent bien jusqu'à 2000 octets sans souci.
-
Merci pour vos analyses.
Hugues, a mon avis c'est du DHCPV6-PD.
Du coup cela ressemblerais à la config OpenWRT ici : https://wiki.openwrt.org/doc/howto/freebox mais sans la free box.
ou peut-être un "grev6tap" (Ethernet GRE tunnel over IPv6).
Par contre pour le IPV4 je vois pas.
Peut être des pistes ici :https://wiki.openwrt.org/doc/uci/network?s[]=tunnel&s[]=ipv6#protocol_gre_gre_tunnel_over_ipv4
Je fais un snif plus tard car pour l'instant j'ai mon gnome qui fait du FPS :-)
-
Hugues, a mon avis c'est du DHCPV6-PD.
Probable, pas certain sans capture :)
Du coup cela ressemblerais à la config OpenWRT ici : https://wiki.openwrt.org/doc/howto/freebox mais sans la free box.
Je ne vois pas le rapport, c'est de la délégation statique là. Du bête routage.
ou peut-être un "grev6tap" (Ethernet GRE tunnel over IPv6).
Heu... Non. C'est du natif.
Par contre pour le IPV4 je vois pas.
C'est du 4Rd. A base d'IPIP et d'A+P d'après mes déductions.
Pas la peine de chercher de doc en fait, y'en a pas. Après je peux aider a en écrire et a décortiquer du pcap
-
le 4rd est pleinement documenté sous forme de RFC: https://tools.ietf.org/html/rfc7600.
c'est du tunneling sur mesh (donc 2 clients qui discutent en IPv4 le font par un tunnel direct au dessus de leur IPv6, ca ne passe par une gateway intermédiaire). La sortie IPv4 vers le reste du monde ce fait via des 'border relay 4rd' ou du NAT64+. cf la doc. Le tout est stateless.
-
Ce n'est pas ce qu'a dit Rani :
Oui, actuellement le trafic entre 2 abonnés "ipfixe ZMD" va passer par un noeud central (Courbevoie) mais on va rajouter par la
suite d'autre passerelle s'il y a vraiment assez de trafic pour le justifier
le 4rd est pleinement documenté sous forme de RFC: https://tools.ietf.org/html/rfc7600.
Je parlais plus de l'implèmentation chez Free.
-
Je parlais plus de l'implèmentation chez Free.
c'est pas 100% la RFC? apres tout y'a qu'eux qui utilisent ca non ? :P