Bonjour Stephane,
Article très intéressant concernant cette RFC dont j'avais déjà entendu parler,
mais que je n'ai encore jamais vu implémenter.
J'ai juste une question, à la fin de l'article tu mentionnes que Bird
l'implémente à travers l'option “local_role”, je ne trouve pas mention de ce
pa
Bonjour,
On 30/05/2022 12:42, geoffroy desvernay via frnog wrote:
Bonjour à toustes,
Depuis bien 2 semaines, les utilisateurs SFR (mobile et dsl) ne peuvent
plus joindre l'IPv6 du réseau renater (as2200), j'ai l'impression que ça
concerne (au moins) le préfixe 2001:660::/32.
la seule source
Depuis quelques minutes, des RTT à 70ms et packet loss massif sur tous les FTTH
de AI dans le Grand Est.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
RAS ici sur une FTTH pro Altitude dans le 67, donc pas général a minima
Hugues - AS2027
> On 31 May 2022, at 14:07, David Ponzone wrote:
>
> Depuis quelques minutes, des RTT à 70ms et packet loss massif sur tous les
> FTTH de AI dans le Grand Est.
>
>
> ---
> Liste
Bonjour,
perso je ne note rien sur mes 2 liens (Free et Adista)
Le 31/05/2022 à 14:07, David Ponzone a écrit :
Depuis quelques minutes, des RTT à 70ms et packet loss massif sur tous les FTTH
de AI dans le Grand Est.
--
Daniel
---
Liste de diffusion du FRnOG
http://w
Quel secteur ?
> Le 31 mai 2022 à 14:10, Daniel via frnog a écrit :
>
> Bonjour,
>
> perso je ne note rien sur mes 2 liens (Free et Adista)
>
> Le 31/05/2022 à 14:07, David Ponzone a écrit :
>> Depuis quelques minutes, des RTT à 70ms et packet loss massif sur tous les
>> FTTH de AI dans le Gr
Le 31/05/2022 à 14:11, David Ponzone a écrit :
Quel secteur ?
67
Le 31 mai 2022 à 14:10, Daniel via frnog a écrit :
Bonjour,
perso je ne note rien sur mes 2 liens (Free et Adista)
Le 31/05/2022 à 14:07, David Ponzone a écrit :
Depuis quelques minutes, des RTT à 70ms et packet loss mass
Après analyse plus fine, c’est plutôt sur 54 et 55.
> Le 31 mai 2022 à 14:10, Hugues Voiturier a écrit :
>
> RAS ici sur une FTTH pro Altitude dans le 67, donc pas général a minima
>
> Hugues - AS2027
>
>> On 31 May 2022, at 14:07, David Ponzone wrote:
>>
>> Depuis quelques minutes, des RT
Ok comme Hughes donc.
C’est donc plutôt 54 et 55, justement le secteur où j’ai des FTTH Kosc étranges
(voir mon mail d’hier).
Et après analyse avec Kosc hier, il s’agit en fait de FTTH sur RIP Altitude sur
OLT Nokia.
Je ne sais pas s’il y a un rapport avec le problème de ce jour cependant.
> Le
Je viens de tester une ligne Vialis/67, tout est également fonctionnel.
Le 31/05/2022 à 14:15, David Ponzone a écrit :
Ok comme Hughes donc.
C’est donc plutôt 54 et 55, justement le secteur où j’ai des FTTH Kosc étranges
(voir mon mail d’hier).
Et après analyse avec Kosc hier, il s’agit en fai
Hello David,
T'es certain que c'est pas l'ONT qui fait n'importe quoi ?
Ou qui a été provisionné en mode "doigt" mouillé...
/Xavier
- Mail original -
> De: "David Ponzone"
> À: "frnog-tech"
> Envoyé: Lundi 30 Mai 2022 14:50:52
> Objet: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?
Un ONT qui arrive à décrypter les trames de tous les clients d’une boucle PON ?
J’en veux bien un d’ONT comme ça, ça peut servir :)
J’ai ça chez 3 clients, au moins.
> Le 31 mai 2022 à 15:12, Xavier Beaudouin via frnog a écrit :
>
> Hello David,
>
> T'es certain que c'est pas l'ONT qui fait n'
Techniquement y a des gens qui ont réussi a bidouiller le linux dedans pour ce
genre de chose...
Donc si le machin est foireux, ou avec un bug qui est apparu dans le temps...
c'est faisable vu la qualité du code dans le linux embarqué...
/Xavoer
---
Liste de diffusion
Et un ONT pourrait décoder sans connaitre le SLID des autres ONT sur la boucle ?
Ca serait quand même une faiblesse légendaire dans la techno….
Ce qui est quand même étonnant c’est que je ne vois pas tout le traffic (ou
alors les autres clients font pas grand chose avec leur FTTH).
Je vais finir
Bonjour,
On 31/05/2022 10:26, Willy Manga wrote:
Il y a pourtant plusieurs routes qui mènent vers AS2200 (RENATER) pour
ce préfixe IPv6 . Exemple en regardant ici
https://lg.ring.nlnog.net/prefix_detail/lg01/ipv6?q=2001:660::/32
A mon humble avis, il faudrait regarder du côté du réseau de SFR.
Le Mon, May 30, 2022 at 02:50:52PM +0200, David Ponzone
[david.ponz...@gmail.com] a écrit:
> Il y a quelque chose de pourri au royaume du FTTH.
>
> Chez un client FTTH (sur Kosc) dans le Grand Est, je reçois du traffic
> entrant destiné à d???autres clients.
En PPPoE ?
Si oui, Tu reçois ça au ni
>
> En PPPoE ?
> Si oui, Tu reçois ça au niveau "E" ou "PPP" ???
Les 2 :)
Si je prends la trace au niveau E, je vois les trames PPPoE de « tout le monde
».
Si je la prends au niveau de ma session PPPoE, je vois les paquets IP aussi de
tout le monde...
Ca, c’est pas normal, donc je pense que c’
C’est rentré dans l’ordre sur 54 et 55.
> Le 31 mai 2022 à 14:18, Daniel via frnog a écrit :
>
> Je viens de tester une ligne Vialis/67, tout est également fonctionnel.
>
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Bonjour,
dans beaucoup de technologies réseau que connaît on à le choix de définir
les algo de chiffrement utilisées, le premier niveau étant "None".
J'ai déjà vu des déploiements ou c'était le cas ;-) et c'est peut être ce
que vous observez.
Le mar. 31 mai 2022 à 15:39, David Ponzone a
écrit :
Que le traffic ne soit pas crypté ne signifie pas que tous les ONT le
forwardent vers le CPE.
Sinon je vois mal comment le CPE du client va faire pour gérer sur son port 1G
un max de 2.4Gbps de traffic dont une grrrande partie n’est pas pour lui.
Ca serait pathétique de la part de la techno.
L’ON
Bonjour,
https://chiffrer.info/
A bientôt.
> -Message d'origine-
> De : frnog-requ...@frnog.org De la part de David
> Ponzone
> Envoyé : mardi 31 mai 2022 16:09
> À : Benoît Grangé
> Cc : Xavier Beaudouin ; frnog-tech
> Objet : Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?
>
>
Dans la technologie GPON tous les ONT d'un PON reçoivent le trafic de tous
les ONT du PON dans le sens descendant ,d'où la nécessité de l'encryptage.
Le TDMA n'est utilisé que dans le sens montant.
Le mar. 31 mai 2022 à 16:09, David Ponzone a
écrit :
> Que le traffic ne soit pas crypté ne signif
Ok donc la sélection du traffic qui concerne le CPE ne repose que sur le
cryptage (coucou Gary), parce que effectivement, et merci pour la correction,
dans le sens descendant, il n’y a qu’un émetteur donc pas de problème de
collision, donc pas besoin de TDM.
Si c’est donc bien ça qui déconne su
Bonjour,
Déjà eu un souci à peu près similaire sur la métropole lilloise avec Kosc en
2019 .
Je recevais les session ppp d'autres clients avec des magicnumber différents
et mon routeur n'aimait pas vraiment (il faisait tomber ma propre session)
Du retour que j'en ai eu, il s'agissait d'un souci
Les spécialistes du GPON me corrigeront mais il me semble que le
chiffrage peut être optionnel (même si c'est vivement déconseillé)
Cela n’empêche pas l'ont de faire le tri entre ce qui le concerne ou pas
(via un id, le pcbd je crois). Donc pas de risque de saturer le lien
entre l'ont et le cp
Chez un client je vois le traffic descendant des autres mais chez un autre
client, je vois le traffic montant des autres.
Et ça c’est plus embêtant, parce qu’en GPON, les splitters sont filtrants dans
le sens montant, donc c’est pas possible, sauf si c’est l’OLT qui renvoie le
traffic up->down.
Le Port-Id dans la Gem Frame (après le pcbd) permet d'identifier l'ONT...
Le mar. 31 mai 2022 à 17:24, Raphael Mazelier a écrit :
> Les spécialistes du GPON me corrigeront mais il me semble que le chiffrage
> peut être optionnel (même si c'est vivement déconseillé)
>
> Cela n’empêche pas l'ont d
Ok donc dans mon cas, on a bien 2 problèmes:
-que ça soit en clair
-que je puisse voir le traffic d’autres Port-Id
Est-ce qu’un ONT sans Port-ID n’aurait pas tendance à prendre tout le traffic ?
> Le 31 mai 2022 à 17:43, Patrick Chollat a écrit :
>
> Le Port-Id dans la Gem Frame (après le pcbd)
Non. Un ONT sans port-id ne peut pas faire passer de trafic.
Le port-id correspond à un n° de GEM (canal de transmission) associé à
l'ONT et négocié entre OLT et ONT au démarrage de l'ONT.
Le mar. 31 mai 2022 à 17:46, David Ponzone a
écrit :
> Ok donc dans mon cas, on a bien 2 problèmes:
> -qu
Alors déjà que tu puisse voir le trafic downstream des autres clients
c'est étrange. Mais soit admettons les datas sont la à ta porte donc si
le trafic est en clair et que l'ont se met en mode sniffing (ca doit
exister) pourquoi pas.
Mais alors l'upstream alors la je vois même pas comment c'es
Bonsoir à tous,
J’ai peu d’espoir mais savez-vous s’il existe un endroit où on serait
susceptible d’avoir une idée (en direct ou via un post sur un blog
post-match) des metrics de Prime Vidéo pendant un match comme celui de ce
soir ?
Ou à défaut une estimation de ce que ça entraîne comme usage de
Le 30/05/2022 à 14:50, David Ponzone a écrit :
Il y a quelque chose de pourri au royaume du FTTH.
Chez un client FTTH (sur Kosc) dans le Grand Est, je reçois du traffic entrant
destiné à d’autres clients.
Difficile de se tromper: IP source et destination ne sont pas celles de mon
client, et pa
> Le 31 mai 2022 à 21:55, Raphael Mazelier a écrit :
>
> Alors déjà que tu puisse voir le trafic downstream des autres clients c'est
> étrange. Mais soit admettons les datas sont la à ta porte donc si le trafic
> est en clair et que l'ont se met en mode sniffing (ca doit exister) pourquoi
> pa
33 matches
Mail list logo
