|
Description de la tâche
Je suis abonné et connecté à Free depuis le 16 avril, sur la plaque ZMD de Niort construite par Orange, à Aiffres (NRO/NRA=79003AIF), en fibre optique (il s’agit d’une migration depuis un accès Orange qui ne causait aucun problème avant pendant plus d’un an, qui n’avait jamais aucune perte).
Visiblement, vous y effectuez la collecte en IPv6 natif (et utilisez une encapsulation pour transporter IPv4).
Je constate que la FreeBox Revolution depuis le firmware 3.5.2 (qui a été installé dans la nuit de vendredi 25 avril à samedi 26 avril, en remplacement du firmware d’origine (sans doute, 3.5.0 mais j’ai oublié de le noter) a de grosses anomalies dans la gestion de bout en bout des MTU (pour TCP et UDP), y compris pour le segment réseau local.
Le protocole PMTUD ne fonctionne pas du tout (pourtant il est obligatoire pour IPv6), l’ajustement de taille des MTU ne se fait pas, la fragmentation IP a lieu, mais n’est pas conforme. De plus sur le segment IP6 WAN.
Le résultat est un débit catastrophique (vous avez sans doute déployé pour y remédier un tunnel de secours, permettant quand même de transporter les trames Ethernet non standards, mais qui ne passe pas par la route normale, mais est utilisé apparemment maintenant pour les utilisateurs de la plaque de Niort ayant une Freebox Revolution déjà migrée en 3.5.2, et transitant apparemment via des lignes optiques de SFR et OVH/Completel, mais ce tunnel est largement surchargé).
Cependant même ce tunnel (qui véhicule à la fois votre IPv6 et votre IPv4 est très instable et filtre des paquets ICMPv4 et surtout ICMPv6 indispensables). Je ne sais pas ce que fait la pile TCP/IP interne à ce firmware 3.5.2 de la Freebox Revolution, mais ça marche très mal, et n’importe quelle session TCP un peu trop longue finit par ralentir, à attendre des aquittements qui ne viennent pas ou qui ne viennent plus jamais car l’adaptation de MTU par PMTUD finit par dépasser des contraintes, et des fragments IP sont perdus, et après trop de demandes de renvois, les sessions TCP sont terminés brutalement, on obtient des fichiers tronqués en HTTP par exemple, sans aucun message d’erreur.
Il est impossible de télécharger un fichier de plus de 100 à 150 Mo en continu sur une seule session TCP (aussi bien via Internet que sur le LAN avec le fichier de test 1Go intégré à la Freebox disponible sur Freebox OS). Le seule moyen de transférer des gros fichiers sur Internet c’est par Torrent (sessions TCP courtes, c’est transmis par petits blocs de taille fixe), par exemple les Torrents d’image ISO de distributions Linux connues (par HTTP ça échoue à chaque fois). Impossible de télécharger une image ISO volumineuse par HTTP (par exemple une image de DVD d’installation de Windows) sans passer par l’outil de téléchargement de Microsoft (qui transmet par blocs avec vérifications). On voit cependant que les sessions Torrrent actives sont anormalement interrompues aussi (mais les Torrents peuvent retenter en utilisant d’autres connexions) (ceci affecte autant le client torrent intégré à la Freebox pour télécharger localement sur son disque dur qu’un client Torrent sur le réseau local).
Autre symptome similaire: la télé multiposte ne tient pas plus de 20 à 30 minutes sur une chaine HD: le streaming HTTP servi par la Freebox Player vers le réseau local via la Freebox server (utilisée comme switch) est lui aussi interrompu, les images se figent régulièrement et de plus en plus souvent. Et finalement la lecture s’interrompt brutalement (aussi bien avec le lecteur Flash proposé par Freebox OS, que par Windows Media Player ou avec VLC.
Tout indique que le non fonctionnement de PMTUD (ou le blocage inopiné des trames ICMPv4 ou ICMPv6 nécessaires pour signaler les MTU trop grosses ou permettre d’ajuster la MTU en TCP ou UDP ne fonctionne pas).
Le test de performance en ligne de Netflix dit la même chose en rapportant seulement le débit très faible, et là aussi les émissions sont interrompues inopinément (impossible de regarder un fluix pendant un heure, pas de flux HD disponible).
Même chose avec Youtube (diffusion en HTTP ou UDP multicast avec RTSP je ne sais pas trop): pas plus de 20 minutes en HD puis c’est coupé après de nombreus ralentissements.
Même chose avec les tests de performance de Speedtest.net: le trafic démarre vite pendant 1 ou 2 secondes puis baisse brutalement et ne cesse de chuter lentement. On voit nettement les pauses sans débit se multiplier, de plus en plus longues (ne recevant pas les statuts ICMP de “paquets trop gros”, le PMTUD pense qu’on peut toujours essayer d’augmenter la MTU, et après plusieurs essais, nécessitant de la fragmentation IP, ça finit par arriver, mais difficilement. Lorsque les fragments IP supplémentaires passent à une certaine taille, ils ne sont même plus signalés comme manquants, les tentatives de envois de trames TCP manquantes n’aboutissent plus car elles sont hors du cadre de la fenêtre TCP, et faute de réponse la session TCP tombe).
D’autres tests montrent qu’en UDP il y a un fort rejet de trames ou des trames perdues. Même chose avec des tests ICMP PING REQUEST/REPLY: on peut faire varier la longueur de payload, mais en fait cette payload est reçue tronquée (à 64 caractères par le destinataire qui la renvoie lui aussi tronquée dans l’écho) et les paquets ICMP indiquant des fragments manquants, ou des fragments IP trop gros ne sont jamais reçus.
La Freebox server sembnle bouloir expérimenter une nouvelle méthode non standard d’encapsulation d’IPv4 sur IPv6 sans couche d’adaptation (peut-être pour gagner un tout petit peu de bande passante ou optimiser la mémoire nécessaire dans vos routeurs et supporter plsu de client par vos routeurs avec une commutation un peu plus rapide, mais l’effet obtenu est totalement inverse: IPv6 dans sa version actuelle requiert absolument la prise en charge de PMTUD (alors que c’est facultatif en IPv4).
Ce protocole expérimental que vous avez déployé dans le firmware 3.5.2 de la Freebox Revolution ne fonctionne pas, n’est pas conforme. En zone ZMD où vous collectez le trafic par des opérateurs de transit, ce protocole est incompatible avec leurs équipements qui font des vérifications plus strictes (il est possible que vous ayez voulu aussi encapsuler ICMPv4 directement sur ICMPv6 sans couche d’adaptation et l’utiliser pour faire du routage spécifique par des options IP ajoutées aux trames IP, ou des options de suivi/Mdébogage, et que ces trames ICMP débordent leur MTU autorisées, la partie essentielle de la trame ICMP est perdue/tronquée, il ne reste que les options inutiles et les routeurs transitaires filtrent ces paquets invalides.
En urgence faute de pouvoir faire transiter votre trafic par le canal normal, il doit passer par un VPN établi au niveau Ethernet ou en dessous (comme PPP) pour faire cependant passer votre trafic Ethernet propriétaire et pas conforme. Mais ce VPN est surchargé. Il n’a pas la capacité de transporter les flux des milliers de vos clients sur la plaque de Niort, et même pas juste ceux équipés de Freebox Revolution et ce lien VPN est largement contraint par les règles de transit des autres opérateurs, imposant une règle d’équité des trafics dans les deux sens: règle 2 pour un pour les petites liaisons, amis plutôt 1,5 pour 1 ensuite pour le transit par les gros backbones.
Comme les clients Free sont très largement des particuliers et consomment surtout de la vidéo en streaming les flux sont surtout descendant avec un gros déséquilibre: le download de ces client est contraint par le débiut d’upload très faible lors de la lecture de vidéo en streaming, vous ne pouvez simplement pas acheminer des centaines de clients (ou plus) par un seul de ces VPN (hors vous y injectez aussi bien les flux des clients ADSL/VDSL que fibre: si l’essentiel de ces clients sont en zone quasi rurale ou très éloignés des DSLAMs, ce qui est le cas dans ma commune qui n’a de bon débits ADSL que dans une zone très limitée, le reste n’a du fait de leur atténuation pas plus de 5 ou 6 mégabit/s en download et ne sont même pas éligibles à la télé HD, ce sont ceux-là pourtant qui sont les premiers à utiliser la fibre, d’autant plus que depuis le fibrage quasi terminé de ma commune dans sa partie horizontale, des tas de lignes RTC ont été allongées et sont devenues inéligibles à l’ADSL, c’est le cas chez moi, le passage à la fibre est définitif, il n’y aura plus de retour en arrière, il n’y a plus les lignes les plus courtes nécessaires, les fourreaux ont moins de capacité car de la place a été faite pour la fibre: ne sont restés éligibles que les clients qui avaient déjà une ligne ADSL activée).
Ce phénomène se produit aussi dans la commune de Niort voisine, sur les autres lots de la ZMD, et tous les abonnés Free de la zone (y compris les premiers en test sur les 2 autres communes de Bessines et Charay en cours de fibrage sur la trentaine concernée par le démarrage rapide subventionné en partie par l’agglomération et le département).
Le système de collecte en ZMD (à Niort c’est en partie en AMII, mais des communes de l’agglomération sont hors périmètre de l’AMII et sont davantage subventionnées pour leur fibrage) et en Full IPv6 nécessite une implémentation impeccable des piles TCP/IP de vos Freebox. Ce n’est pas du tout le cas de la Freebox Revolution depuis la version 3.5.2: IPv6 ne fonctionne pas correctement et il n’y a aucun moyen facile de contourner le problème. Votre solution temporaire de routage d’urgence par un VPN ne peut pas absorber le trafic de la zone.
Résultat, panne générale depuis samedi matin, juste un léger mieux lundi dans la journée, à nouveau exécrable en début de soirée et toute la journée fériée du 1er mai (vos abonnés ADSL et fibre sont à domicile et consomment massivement de la vidéo), légéer mieux aujourd’hui en cours de journée, puis à nouveau exécrable à partir de 16h et toute la soirée jusque tard.
Votre VPN ne règle pas tout: le bogue de la Freebox Revolution 3.5.2 est toujours là dans sa partie “switch”. Et ça se voit. Un test de téléchargemetn depuis la Freebox vers le réseau local est tout autant affecté par le problème d’instabilité ou d’indétermination de la MTU qui finit par sortir des cadres et se désynchroniser entre émetteur et récepteur: assez vite TCP ne répond plus, les sessions tombent les unes après les autres après de nombreux échecs de demande de retransmission (qui en plus provoque de la surcharge supplémentaire sur votre réseau de collecte et la capacité de votre VPN de secours à l’absorber).
Bref je demande le retour de ma Freebox en version 3.5.0. Il va falloir revoir vos procédures de test et de montée en charge, et surtout ne plus déployer des versions beta directement chez vos clients non avisés (et en plus sans aucun canal de communication et sans même informer vos services de support client qui ne sont même pas habilités à remonter des tickets d’incidents et ferment les sujets: ils ne sont qu’abilités à tester le segment de la boucle locale, voient que la box est synchronisée et répond correctement à des tests trop simples)
Pourtant le simple test de transfert d’un fichier de 1Go suffit à démontrer le problème (et il pet être effectué directement dans la Freebox Server sanas même avoir à tester le réseau local ou le soupcçonner d’une mauvaise installation (le problème est identique si on débranche complètement la Freebox Server du réseau local, y compris en coupant le wifi, débranchat les cables Ethernet de vos Freeplug CPL, et celuui reliant le Freebox Server au Freebox player: on peut lancer le test en se connectant à distance sur la Freebox via Internet pour accéder à l’interface Freebox OS et on a le même résultat: les téléchargements de test depuis Internet vers le disque dur interne sont très très lents, souvent tronqués, ou corrompus quand on les valide par une somme de controle MD5 ou SHA1 si ces fichiers dépassent environ 100 Mo de taille.
Aucune session TCP ayant reçu déjà 100 Mo (ce qui arrive vite pour un flux TV HD en streaming sur HTTP/1.1) ne tient, que ce soit diffusé en IPv4 ou en IPv6, et votre tunnel de secours est surchargé durant toute la diffusion, seule le flux SD passe il manque des tas d’images, il y a beaucoup trop de demandes de retransmissions ou de resynchronisation du flux pour sauter directement des trames non reçues à temps, et sinon des transmissions en doublon à la lisière de ce timestramp de diffusion, ce qui accroit encore la charge.
Je pense que tous les abonnés en ZMD où vous avez commencé la migration de collecte en Full IPv6, et utilisant la Freebox Revolution avec ce firmware sont concernés (et visiblement cela concerne les communes nouvellement fibrées (mais déjà dégroupées depuis longtemps chez Free en ADSL puis VDSL) et particulièrement dans les zones urbaines les plus denses de ces ZMD où un NRO/NRA est occupé par plsu d’une centaine de clients: vos VPN de secours ne peuvent pas tenir la charge. Le sud-est de la ville de Niort et toute la commune d’Aiffres est impacté (et c’est encore plus visible poru les nouveaux clients qui ont les dernières box prééquipées pour IPv6 et chez qui tout allait bien avant que vous ne les passier en version 3.5.2)
|
