La Fibre
Télécom => Télécom => 
ADSL / VDSL => Discussion démarrée par: Marin le 04 avril 2014 à 21:56:24
-
Bonsoir,
Depuis quelques mois, je rencontre occasionnellement des problèmes de connexion qui peuvent se manifester de la façon suivante :
- Ping qui double (passe de ~30 ms à ~60 ms en pinguant 8.8.8.8).
- Pertes de paquets dans la plupart des cas autour de 10%, pouvant aller jusqu'à 25% dans le pire des cas. (hier, mais ce soir je semble rencontrer une variante un peu plus "soft" du problème avec le ping qui double bien, mais des pertes inexistantes ou quasi-inexistantes).
- Ralentissement général de la navigation, quel que soit le site web.
- Je ne rencontre (ou en tous cas remarque) pas le problème tous les jours, disons quelques fois par mois au maximum.
- Sur une période qui ne dépasse pas quelques minutes ou dizaines de minutes généralement.
- Je ne me souviens pas l'avoir vu en dehors du soir : heure de pointe ?
Quelques éléments de diagnostic, aux moments où le problème survient :
- Si j'effectue le ping directement en me connectant en SSH sur la box, le problème est aussi présent, il ne se trouve donc pas au niveau de mon PC ou du lien entre mon PC et la box.
- La charge CPU de la box n'est pas anormalement élevée.
- Un reboot de la box ne résout pas le problème.
Le problème n'étant pas très récurrent, se présentant sur une période de temps limitée, et ne rendant pas l'utilisation que je fais de ma connexion impossible ou difficile, il ne me gêne pas beaucoup... Mais je suis curieux donc je viens quand même en parler ici :)
En rassemblant ces différents éléments, je me suis dit que l'hypothèse la plus probable serait une saturation au niveau du DSLAM, ou peut-être un peu plus en amont sur le réseau.
- Est-ce que ça vous semble probable ?
- Les saturations des liens DSLAM sont-elles courantes au niveau national ?
- Sont-elles monitorées par les FAI ?
- Donnent-elles souvent lieu à une augmentation de la taille du lien pour conséquence ? Uniquement si le problème est gênant et dure ?
Je suis chez SFR en ADSL, sur le DSLAM 60bez1-r0s0 et le BAS SE100-CRL1-1.
Merci d'avance si vous avez des infos !
-
Il faudrait des mesures permanentes avec graph à l'appui pour faire une analyse.
De là on pourra dire si tu es victime de "l'effet baignoire".
-
- Ping qui double (passe de ~30 ms à ~60 ms en pinguant 8.8.8.8).
En pinguant ton voisin, ça donne quoi ?[/list]
-
Je ne peux pas te dire, le ping est revenu à la normale. En tous cas, quand le problème s'accompagne de pertes de paquets ça se ressent sur tous les sites web, ce qui exclut au moins un problème de saturation de lien avec Google.
Pour ce qui est de pinguer l'adresse IP d'un voisin, j'allais te dire que je n'en ai pas sous la main, mais je me suis rappelé qu'on prenait la vraie adresse IP publique du voisin quand on se connectait sur un hotspot SFR WiFi (pas sûr que ce soit très Hadopi-friendly d'ailleurs, chez Free il y a des plages d'adresses dédiées). Donc je verrai la prochaine fois que le problème se présente.
-
Le problème est de nouveau présent − en fait, je me demande s'il ne serait pas présent tous les soirs ces derniers jours, mais sans que je le remarque beaucoup la plupart du temps...
J'ai récupéré l'adresse IP d'un voisin via SFR WiFi.
Quand je ping ma box depuis l'extérieur (dédié Online), j'obtiens un ping anormal (~ 60 ms), mais quand je ping le voisin, j'obtiens un ping normal (~ 30 ms). Peut-être est-il sur un autre DSLAM.
-
1°) Mise sous surveillance de la connexion sur 48h
2°) Vérification de la présence de ligne Numéris encore fonctionnelle proche du même transport (je ai le numeris)
3°) vérification prise T coté installation client (Est-ce qu'il y a un fax branché dessus? Avant le filtre ou après?)
4°) Si les "bagots" continuent, mesurer les CRC et faire fiabiliser la ligne en commençant par une mutation de broche niveau DSLAM (certains broches fatiguent et doivent être retirées).
5°) Vérification des valeurs avec un NTT (appareil des techniciens d'interventions depuis le DSLMA jusqu'au routeur)
6°) Changement de routeur pour un modèle plus récent (à la charge du FAI) brancher le routeur sur un onduleur + parafoudre et brancher une autre prise T avec filtre et câble RJ11 sur un parafoudre relié à la terre.
7°) Si existence d'un switch, vérifier si le problème perdure avec un autre switch (ils peuvent poser de droles de prblèmes)
8°) Vérifier le parc Informatique (Transmissions de données par troyen)
9°) Transmettre à la cellule expertise "service dégradé": moi, j'adore chercher le petite bête. ^^
-
En relisant le tout, je penche sur une broche défectueuse (partiellement).
Quand le DSLAM est trop sollicité, le broche déconne.
Tu peux demander une fiabilisation de ton transport.
-
Je vais déjà voir pour la surveillance de la connexion sur 48h, mais apparemment ça n'arrive qu'en heure de pointe (genre ~21h30, sinon à cette heure-ci tout est de nouveau stable), donc la plupart des possibilités que tu as énoncé me semblent assez improbables.
Pour l'hypothèse du troyen, ça me semble également improbable, sachant que j'ai vérifié la charge CPU, la montée du ping, ainsi que le trafic réseau, directement en me connectant en SSH sur la box (à moins que la box n'ait été flashée discrètement avec un firmware contenant un rootkit, mais bon...).
-
En relisant le tout, je penche sur une broche défectueuse (partiellement).
Quand le DSLAM est trop sollicité, le broche déconne.
Hein ?
Tu peux demander une fiabilisation de ton transport.
Hum sur une ligne dégroupée... LBE, circulez, y a rien à voir !
-
Tu peux demander quand même une fiabilisation de ligne avec mutation de transport. Je dois parler chinois pour certains, mais le Niveau 2 est supposé savoir de quoi je parle.
Il y a un contrat, le service est peut-être dégradé en heure de pointe, il faut écarter les hypothèses, mêmes les plus farfelues.
Une fois qu'on s'est assuré que la partie boucle locale est bonne (ou fiabilisée), là tu pourras attaquer le diagnostique approfondi.
Vérifie ce que propose le contrat avant quand même, car ils pourraient te dire que ce n'est pas prévu dans le contrat, on ne sait jamais.
Bon courage.
-
J'ai déjà demandé la mise en place d'un smokeping, ça me semble déjà être une première chose à faire avant d'aller embêter le SAV pour faire des vérifications sur ma ligne :)
-
Tu utilises un ou des VPN? (Sachant que l'opérateur en utilise toujours un au minimum mais c'est pas toujours visible coté client).
-
Pas de VPN, et la montée de ping se remarque aussi quand je ping mon adresse IP depuis l'extérieur.
-
Vu que tu as pas de de VPN à toi (il y en a toujours coté opérateurs, mais ils ne sont pas visibles sauf prestation à part), et que tu ne veux pas solliciter le SAV de suite, il faut effet analyser le traffic pendant l'heure de pointe ou le ralentissement.
Tu peux essayer de saturer ton routeur en lui balançant des ping étendus à grosses trames depuis plusieurs serveurs, vers plusieurs autres serveurs, fait le chauffer et voit ce que ça donne au niveau de son CPU et de son cache.
Mais le plus intéressant est de voir ce qu'il se passe vraiment à l'heure de pointe (CPU, Memoire, Flux sur les ports, Captures et analyse des trames).
Si ce n'est pas pressé, bien sur. :-)
-
Vu que tu as pas de de VPN à toi
Qu'est-ce que ça pourrait changer ?
Mais le plus intéressant est de voir ce qu'il se passe vraiment à l'heure de pointe (CPU, Memoire, Flux sur les ports, Captures et analyse des trames).
Comme je l'ai dit dans le premier message, je l'ai déjà fait et je n'ai rien constaté d'anormal. Usage CPU et RAM bas, trafic réseau à son minimum.
-
Je bosse pas mal sur des cas comme ça.
De 1, je considère un accès XL sans défaut comme une anomalie, la normalité, c'est un service dégradé (Vive le cuivre).
De 2, on peut chercher la petite bête pendant des heures alors que le problème peut être pile sous notre nez.
De 3, le réseau est fait par des hommes, pour des hommes : il est donc faillible.
Il existe énormèment de possibilités pour faire un diagnostic avancé.
Si tu veux exclure un problème de ton réseau avant de faire marcher le SAV, il faudrait faire saturer le routeur de diverses sollicitations et vérifier le comportement du CPU, vérifier aussi l'alimentation qui peut vieillir et ne plus suivre les fortes sollicitations (je te raconte pas le nombre de pannes ou de services dégradés à cause des alimentations (même pour du Cisco)).
Enfin, je ferais une analyse de trames en temps normal puis en période dégradée.
Le reste est du ressort du SAV qui sont supposés avoir tous les outils de diagnostiques nécessaires.
On trouve toujours le problème, mais des fois, ça prend beaucoup de temps.
Vive les réseaux ! ;-)
-
Enfin bon, ça sent quand même la saturation toute simple d'un lien de collecte ce truc...
-
On trouve toujours des solutions. Si tu dois absolument éviter cet engorgement des données à heure de pointe, tu peux demander au SAV et aux commerciaux d'autres types d'accès, il y a des moyens pour prioriser des flux par rapport à d'autres.
On peu aussi installer des accélérateurs, c'est ce que fait Airbus avec OBS, mais là, cet vraiment un niveau au dessus. ^^
-
On parle ici d'un accès GP tout de même.
-
Est-ce qu'on a une analyse des trames en période de pointe à tout hasard? (Dernier recourt avant le SAV).
-
J'ai finalement eu la confirmation qu'il y a un problème de saturation, et que le problème est en cours de résolution.
Est-ce qu'on a une analyse des trames en période de pointe à tout hasard? (Dernier recourt avant le SAV).
Oui, c'est ce que j'avais fait, et encore une fois il n'y avait rien d'anormal, pas de trafic particulier : le problème se présentait quand la connexion était complètement inutilisée (mis à part quelques paquets périodiques sur le VC 8/35 dont la présence est normale, de type ping PPP LCP ou ARP venant du DSLAM).
-
"Oui, c'est ce que j'avais fait, et encore une fois il n'y avait rien d'anormal, pas de trafic particulier : le problème se présentait quand la connexion était complètement inutilisée (mis à part quelques paquets périodiques sur le VC 8/35 dont la présence est normale, de type ping PPP LCP ou ARP venant du DSLAM)." >:(
Nom de Dieu! Qui a dit qu'il ne fallait pas voir les broches sur les réglettes du DSLAM!
Que la ligne est Bonne aux Essais? Non, Non et mille fois non! Il est quasiment impossible de savoir si une broche est réellement bonne sans intervention d'un technicien avec un NTT pour effectuer les tests nécessaires. Souvent, une bonne déconstruction, suivit d'une reconstruction de la ligne support suffit à remettre les pendules à l'heure dans la suite d'équipements impliqués dans la distribution de l'accès.
ça m'énerve ça
Je connais des formateurs en technos ADSL si certains en on besoin (pas toi, ne t'inquiète pas).
Heureusement qu'ils sont dessus. S'ils ont un doute, il muteront le transport (a priori).
ça va s'arranger, ça s'arrange toujours.
Et si ça se trouve tu vas bientôt être éligible au VDSL2+ Professionnel (avant de passer à la fibre bien entendu, c'est quand même la seule solution à long terme).
Je suis très content pour toi qu'il aient trouvé un défaut et qu'il aient déclenché une intervention.
Bonne continuation. :D
-
Nom de Dieu! Qui a dit qu'il ne fallait pas voir les broches sur les réglettes du DSLAM!
En l’occurrence le problème n'a strictement rien à voir avec ça.
Et si ça se trouve tu vas bientôt être éligible au VDSL2+ Professionnel (avant de passer à la fibre bien entendu, c'est quand même la seule solution à long terme).
Tu voulais parler de "VDSL2" ? Parce que "VDSL2+ Professionnel" ça ne me parle pas.
Je suis très content pour toi qu'il aient trouvé un défaut et qu'il aient déclenché une intervention.
C'est pas un défaut mais une saturation.
-
Le VDSL2+ est sur les rails. Nous le testons actuellement en maquette avec Alcatel.
S'il le comportement de l'accès réseau ne suis plus lorsqu'on le pousse à saturation (Percs par exemple) nous categorison la ligne en défaut. Bien sûr, il faut vérifier tout le transport. Mais sans avoir accès aux données de notre utilisateur ici présent, cela revient un peu à travailler à l'aveugle.
-
Je ne comprends pas pourquoi vous parlez de fiabilisation de ligne. C'est quand même très simple de voir si c'est la ligne qui est en cause ou si c'est en amont du DSLAM que ça sature : au moment des pertes de paquet, il suffit de regarder le taux d'erreur dans le modem ADSL. S'il n'y a que très peu d'erreur, alors la ligne est fiable, et que le problème est en amont du DSLAM, c'est tout. Aucune perte de paquet ne peut être due à la qualité de la ligne cuivre si le modem ADSL ne déclare pas ou peu d'erreur.
Leon.
-
Il y a des pièges...
Par exemple l'établissement de la session client entre la BAS et le Routeur Client.
La synchronisation DSL sera OK et c'est tout, pas de Ping, pas de Telnet.
Il y a un paquet de défauts intermédiaires, mais il est vrai que de temps en temps il faut prendre du recul et ce demander si ce n'est pas un problème tout simple (ce qui m'arrive souvent). Oups
-
Le VDSL2+ est sur les rails. Nous le testons actuellement en maquette avec Alcatel.
S'il le comportement de l'accès réseau ne suis plus lorsqu'on le pousse à saturation (Percs par exemple) nous categorison la ligne en défaut. Bien sûr, il faut vérifier tout le transport. Mais sans avoir accès aux données de notre utilisateur ici présent, cela revient un peu à travailler à l'aveugle.
Le VDSL2+ apporte quoi de plus par rapport au VDSL2 ?
-
Je veux bien le nom de la norme du VDSL2+ d'ailleurs.
VDSL -> ITU G.993.1
VDSL2 -> ITU G.993.2
VDSL2+ -> ?
-
Le VDSL2+ est utilisé en Belgique par Belgacom (30Mb/s).
La norme n'est pas encore officialisée, pas de RFC encore les recherches sont toujours en cours, et les algorithmes sont régulièrement améliorés.
D'où l’utilisation de maquettes chez Orange Buisness Services.
Pour l'instant on est en plein déploiement de DSLE pour C2E et CE LAN, beaucoup plus intéressants et surtout pas besoin de tirer une fibre entre le client et le dernier répartiteur (DSLAM Zone d'Ombre) pour l'instant.
C'est une solution provisoire et économique avant la Fibre Optique Directe chez les clients Buisness.
-
ça repousse toujours la mise en place de la fibre mais un jour il faudra bien passer à la fibre à un moment
On a le temps d'attendre avant de pouvoir en profiter du VDSL2+
-
"VDSL2+" ça ne serait pas du VDSL2 Vectoring plutôt ?
Cf. http://www.belgacom.com/be-fr/newsdetail/ND_20140219_alcatel_lucent.page (http://www.belgacom.com/be-fr/newsdetail/ND_20140219_alcatel_lucent.page)
-
Quasiment, mais avec des algorithmes différents...
Il n'y a pas de solution miracle avec les lignes existantes.
Ils bossent dessus.
-
c'est bien, on commence a être à la ramasse en France...
-
C'est pour ça que le cuivre n'est pas la solution à long terme, surtout avec les montées en débit...
Pour la fibre en revanche, il y a de la marge et on en repousse sans cesse les limites.
-
C'est pour ça que le cuivre n'est pas la solution à long terme, surtout avec les montées en débit...
Pour la fibre en revanche, il y a de la marge et on en repousse sans cesse les limites.
Je prefere ne pas attendre 30 ans avoir le THD en France exclusivement via la FTTH, mais de mettre le paquet dans toutes les techno possibles pour réduire la fracture numérique dans les 5 prochaines années.
Le FTTdp est une bonne approche si elle imposé selon des règles définie par l'ARCEP (logement ancien etc...) en sachant qu'une option FTTH soit possible dans le futur et mutualisable.
-
En 2004, le projet THD était déjà amorcé et devait être assuré intégralement par France Télécom, coût de l'opération estimé à l'époque: 20 à 40 Milliards pour 10 ans de travaux.
Le projet a été abandonné car il posait des problèmes pour la mise en place des nouveaux opérateurs.
En 2014 le projet THD pour les opérateurs participant ET les départements (collectivités locales, régions, départements...) est estimé entre 70 et 90 Milliards d'Euros pour 16 ans de travaux.
On aurait peut-être déjà tous la fibre si le projet de 2004 aurait été poursuivit (mais les règles de concurrences et l'Europe étaient contres).
Maintenant faites le calcul total des pertes et du manque à gagner pour les Français et nos entreprises.
Bien entendu, il ne faut pas le crier sur tous les toits, ce serait mal vu. ;)
-
Bonjour,
si le prix du déploiement a autant augmenté en 10 ans, c'est peut être aussi parce qu'il y a eu sous-estimation avant non ?
Sinon pourquoi autant d'augmentation ?
@Amon-Ra, dans pas mal d'endroit, les départements ont financés des NRA-med qui permettant de raccourcir les lignes et pour certains d'avoir le VDSL dans certains villages.
Le déploiement nécessaire pour le FTTdp ou le FTTH est quand même très très similaire (à 10 m près), çà ne fera pas arriver le haut débit plus vite partout.
-
Le coût du matériel et de la main d’œuvre à beaucoup augmenté en 10 ans apparemment.
On pense que c'est lié à l'utilisation de prestataires, ils sont plus flexibles, mais plus chers.
Il y a un rapport national (mais assez confidentiel, forcèment) à ce sujet, il faut le retrouver.
-
Le déploiement nécessaire pour le FTTdp ou le FTTH est quand même très très similaire (à 10 m près), çà ne fera pas arriver le haut débit plus vite partout.
Le but du FTTdp c'est de ne pas à avoir à entrer dans les logements pour y installer les prises optique car c'est la cause d'une grosse partie des échec de raccordement clients aujourd'hui.
Les raisons sont multiples: Le propriétaire (qui n'est pas forcèment l'occupant) s'y oppose, et le locataire ne prends pas le risque de donner son accord quand même et risquer sa caution.
Il y a les problèmes de passage de la fibre dans les parties communes, ou encore dans le logement: Les tubes sont parfois bouchés (quand il y en a), et tout le monde n'aime pas les goulottes en plastique posées au pisto-colle , ça peux se comprendre. Enfin, il y a les syndics réticents (ou qui tentent le coup de poker de toucher un backshish de l'opérateur, après tout ils font comme ça pour l'antenne TV et les peintures, alors...), ou le fait que le bâti est adducté en aérien et qu'a l'heure actuelle , les zones sur lesquelles l'aérien est accepté et installé sont excessivement rare (peut-être en attendant l'hypothétique rénovation des enrobées)
=> Ce qu'on peut en déduire c'est que les opérateurs (aujourd'hui: Orange) qui cherchent à favoriser le FTTdp ne l'envisagent que dans les zones ou le fibrage horizontal est déjà bien planifié , voire entamé. En particulier, le coût du FTTdp est pratiquement identique au FTTH, puisqu'il faut amener la fibre dans la rue, donc faire le travail de fourmi , au contraire des offres type NRA-MED.
-
En dernier recours, c'est au syndicat des copropriétaires que revient la décision, pas au syndic qui n'est qu'un administrateur payé pour gérer les affaires courantes!
-
En dernier recours, c'est au syndicat des copropriétaires que revient la décision, pas au syndic qui n'est qu'un administrateur payé pour gérer les affaires courantes!
Tu sais aussi bien que moi que dans les grandes villes, dans les grands immeubles impersonnels, c'est le syndic qui prends toutes les décisions & les imposent ensuite aux co-propriétaires (ceux-ci n'étant souvent même pas habitants). Bien souvent, les copropriétaires se tirent dans les pattes plutôt que de prendre en main les dossiers, laissant ainsi le champs libre aux extérieurs pour faire ce qu'ils veulent.
-
Il faut écrire directement aux membres du conseil syndical.
-
Ça prend des proportions amusantes : ce soir (heure de pointe, vers 21h20), 60 % de pertes de paquets, au point de faire sauter la session PPP... et pourtant, la ligne ADSL reste synchronisée !
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=2 ttl=47 time=61.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=47 time=61.5 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=47 time=62.5 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=47 time=65.7 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=47 time=61.6 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=47 time=60.9 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=47 time=63.6 ms
64 bytes from 8.8.8.8: icmp_seq=21 ttl=47 time=65.9 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=47 time=62.4 ms
64 bytes from 8.8.8.8: icmp_seq=26 ttl=47 time=60.1 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=47 time=61.5 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=47 time=62.6 ms
64 bytes from 8.8.8.8: icmp_seq=31 ttl=47 time=60.5 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=47 time=62.3 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=47 time=63.1 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=47 time=61.7 ms
64 bytes from 8.8.8.8: icmp_seq=41 ttl=47 time=62.6 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=47 time=61.1 ms
64 bytes from 8.8.8.8: icmp_seq=43 ttl=47 time=62.9 ms
64 bytes from 8.8.8.8: icmp_seq=48 ttl=47 time=62.8 ms
64 bytes from 8.8.8.8: icmp_seq=51 ttl=47 time=63.8 ms
64 bytes from 8.8.8.8: icmp_seq=52 ttl=47 time=62.0 ms
64 bytes from 8.8.8.8: icmp_seq=54 ttl=47 time=63.5 ms
64 bytes from 8.8.8.8: icmp_seq=56 ttl=47 time=60.9 ms
64 bytes from 8.8.8.8: icmp_seq=63 ttl=47 time=63.9 ms
64 bytes from 8.8.8.8: icmp_seq=66 ttl=47 time=63.3 ms
64 bytes from 8.8.8.8: icmp_seq=68 ttl=47 time=61.1 ms
64 bytes from 8.8.8.8: icmp_seq=70 ttl=47 time=64.2 ms
64 bytes from 8.8.8.8: icmp_seq=73 ttl=47 time=59.8 ms
64 bytes from 8.8.8.8: icmp_seq=74 ttl=47 time=64.7 ms
64 bytes from 8.8.8.8: icmp_seq=75 ttl=47 time=37.3 ms
64 bytes from 8.8.8.8: icmp_seq=76 ttl=47 time=37.2 ms
64 bytes from 8.8.8.8: icmp_seq=77 ttl=47 time=62.7 ms
64 bytes from 8.8.8.8: icmp_seq=78 ttl=47 time=60.8 ms
64 bytes from 8.8.8.8: icmp_seq=80 ttl=47 time=61.4 ms
64 bytes from 8.8.8.8: icmp_seq=82 ttl=47 time=63.1 ms
From 192.168.1.1 icmp_seq=88 Destination Host Unreachable
From 192.168.1.1 icmp_seq=89 Destination Host Unreachable
From 192.168.1.1 icmp_seq=90 Destination Host Unreachable
From 192.168.1.1 icmp_seq=91 Destination Host Unreachable
^C
--- 8.8.8.8 ping statistics ---
91 packets transmitted, 36 received, +4 errors, 60% packet loss, time 90249ms
rtt min/avg/max/mdev = 37.296/61.073/65.942/5.940 ms
-
Eh ben :o Et c'est possible qu'Orange ou SFR pallie au problème ?
-
Bonjour, j’ai exactement le meme probleme quasiment tout les jours, mon voisin à 2 rue de chez moi a le meme soucis, on a des pertes de connexions de 30 secondes au meme moment, on est sur le meme DSLAM, on est chez RED en VDSL2
(https://image.noelshack.com/fichiers/2019/37/3/1568183506-sans-titre-2.jpg)