Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

Bonjour !

En fait, c’est pas compliqué, ça passe juste plus du tout chez Orange Pro 
Mobile. 
Et en 2024, devoir bricoler des APNs ou des MTU pour que ça marche, c’est une 
honte absolue. Intéressant intellectuellement pour comprendre, mais 
inadmissible en production.
Tu changes d’opérateur ou tu essaies en Wifi, et hop, connecté en quelques 
centaines de millisecondes.

Je suis en discussion avec le client pour savoir ce qu’on met en priorité: 
accélération du déploiement de la solution ZTNA, quitte à mettre de eSIM 
d’opérateurs alternatifs pour qu’on puisse terminer le projet.

> Le 6 mai 2024 à 11:46, Thierry Chich  a écrit :
> 
> Bonjour
> 
> 
> Moi je ferais quand même une capture sur un qui qui marche et un qui marche 
> pas. Le coup de l'isakmp fragmenté, je l'ai eu aussi. Pas avec du forti en 
> revanche. Le certif était gros, le paquet isakmp passait pas en 1500 octets, 
> et une maj d'un ios cisco avait décidé qu'il fallait droppé. Alors oui, la 
> phase 1 est sensé fonctionner, mais bon.
> 
> 
> Le 02/05/2024 à 20:53, Philippe ASTIER via frnog a écrit :
>> Oui ben j’ai commencé le debug, (diag debug application ike -1) et comparé 
>> ce qui se passe en wifi vs 4G/5G Orange.
>> 
>> Pour le moment, à part le fait que ça coupe dans le deuxième cas, la 
>> négociation a l’air vraiment identique.
>> Je vais tâcher de faire du vrai diff entre les deux, il y a forcément un 
>> truc qui m’échappe.
>> 
>> Mais bon sang, qu’est-ce que ça cause ces logs !….
>> 
>> Le 2 mai 2024 à 19:30, David Ponzone  a écrit :
>> 
>> Vincent,
>> 
>> Ca bloque pas chez Orange puisque Philippe dit que la négociation 
>> Phase1/Phase2 semble bien se passer et puis paf!
>> 
>> Philippe,
>> 
>> Tu vas devoir entrer dans le monde du debug Forti :)
>> 
>> David
>> 
>> Le 2 mai 2024 à 19:19, Vincent Tondellier via frnog  a 
>> écrit :
>> 
>> On jeudi 2 mai 2024 19 h 04 min 32 s CEST, Philippe ASTIER via frnog wrote:
>> ...
>> 
>> - sur la partie « split-tuneling », je ne vois pas trop le rapport.
>> 
>> Aucun, c'est la description du bug de David en SSL qui y ressemble
>> 
>> Ce que je trouve désolant, c’est que quand le client qui se connecte est sur 
>> n’importe quel autre réseau, avec ou sans IPv6, ou chez Free / FreePro, ben 
>> ça juste fonctionne sans aucun souci.
>> Donc je veux bien qu’il y ait aussi un bug qui traine chez Forti, mais  il 
>> n’y a que chez Orange (offre Orange Pro) que ça semble se déclencher, et 
>> c’est pénible.
>> 
>> C'est ce que je dis, il y a un truc sur l'IPv4 (uniquement) chez orange 
>> (uniquement) qui bloque l'udp et/ou l'esp, comme un proxy tcp only.
>> C'est en tout cas ce que je constate.
>> Activer ou désactiver l'IPv6 d'un coté seulement n'y changera rien.
>> 
>> Vincent.
>> 
>> 
>> Le 2 mai 2024 à 15:15, Vincent Tondellier via frnog  a 
>> écrit :
>> On jeudi 2 mai 2024 14 h 54 min 53 s CEST, David Ponzone wrote:
>> On doit pas parler du même problème.
>> Celui auquel je pense doit dater de 2021, concerne que SSL/Forticlient à 
>> priori, et se déclenche quand le client a accès à IPv6 alors que le serveur 
>> n’est pas dispo en IPv6.
>> Je ne connais pas fortinet, mais la description ressemble a un problème de 
>> split tunneling.
>> Cependant, Philippe parlait d'un problème avec IKEv2, pas avec SSL/ppp.
>> « A good IPv6 is a disabled one ».
>> Sans vouloir nourrir le troll, sur les réseaux mobiles, l'IPv4 est la 
>> plupart du temps cassé (CGNAT, DNS64 et autre) pour autre chose que du web 
>> simple.
>> IPv6, lui, fonctionne correctement.
>> Vincent.
>> ...
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
>> 
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> -- 
> 
> Thierry CHICH
> 
> x...@ac-clermont.fr <mailto:dsi-rese...@ac-clermont.fr>
> 
> <http://www.ac-clermont.fr>
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

> Le 3 mai 2024 à 08:54, Dev Mart  a écrit :
> 
> Hello, tu as aucun log dans VPN events pour t'aiguiller sur le problème ?

Salut,

Alors les VPN Events, ils ne voient pas grand chose, tout est « success » et 
joliment vert.

Non, les vrais logs, tu les as en CLI :

diag debug application ike -1
diag debug enable

Et aussi  diagnose vpn ike log-filter … si tu ne veux pas mourrir sous les logs 
des autres tunnels VPN qui ne t’intéressent pas.

Le seul souci c’est que c’est TRES verbose, donc ça prend du temps à lire et 
digérer.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

> On Thu, May 2, 2024, at 19:04, Philippe ASTIER via frnog wrote:
>> - les Forti sont exclusivement en IPv4 (eh oui, vous pourrez me 
>> troller, je suis un fervent défenseur d’IPv6, mais pas dans ce cas ;p )
> 
> Pourquoi ?
> Tu peux avoir l'IPv6 actif uniquement sur le cote WAN du FW (qui est deja 
> suppose etre globalement joignable en v4).

C’est juste une conf historique d’un temps où leur FTTO (et SDSL avant) n’avait 
pas d’IPv6.

Un truc vient de jaillir dans ma tête… J’ai cru voir hier dans les logs que le 
NAT-T n’était pas bien détecté en 4G/5G… 
Comme si quand le client est en IPv6, il ne se voit pas derrière un NAT (ce qui 
d’un point de vue v6 est juste, mais faux en v4…).

Ca irait dans le sens de s’activer l’APN v6.

Je vais me retaper les 3000 lignes de logs et en refaire avec le client… Happy 
Friday.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

> On Thu, May 2, 2024, at 12:56, David Ponzone wrote:
>> Désactive IPv6 sur le client pour voir.
> 
> ??? En 2024 AD ???

Oui, je suis assez d’accord, et pour mémoire, sur iOS/iPadOS, c’est totalement 
impossible en cellulaire (sauf bidouilles APN, et encore, je vais tâcher de 
tester.

> Pourquoi pas activer IPv6 sur le head-end (au moins cote WAN) "juste pour 
> voir" ?

Oui, ok, pour voir ça me va, ça ne coûte pas grand chose, et ça ne changera 
rien à mes confs.

> Sinon, cote Forti, il y a la "firewall authentication", mais c'est un truc 
> qui va plutot (vaguement) dans le sens du ZTNA (et ca implique que l'ensemble 
> des ressources exposes aient des IP publiques - plus simple en v6 qu'en v4)

Comme dit précédemmentt, on devrait implanter d’ici l’été une solution de ZTNA 
(JAMF Private Access), qui établit un tunnel wireguard avec l’infra JAMF, et on 
est en IKEv2 fixe vers l’infra du client. 
Je teste depuis quelques semaines chez moi, ça marche rudement bien, avec 
contrôle d’accès depuis le client (identité, conformité et ce qu’on veut), et 
possible traffic vectoring, DNS privé. Du coup aucune exposition publique de 
l’infra du client.
Je ne voulais pas révolutionner la conf des Forti avant ça.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

Oui ben j’ai commencé le debug, (diag debug application ike -1) et comparé ce 
qui se passe en wifi vs 4G/5G Orange.

Pour le moment, à part le fait que ça coupe dans le deuxième cas, la 
négociation a l’air vraiment identique.
Je vais tâcher de faire du vrai diff entre les deux, il y a forcément un truc 
qui m’échappe.

Mais bon sang, qu’est-ce que ça cause ces logs !….

Le 2 mai 2024 à 19:30, David Ponzone  a écrit :

Vincent,

Ca bloque pas chez Orange puisque Philippe dit que la négociation Phase1/Phase2 
semble bien se passer et puis paf!

Philippe,

Tu vas devoir entrer dans le monde du debug Forti :)

David

Le 2 mai 2024 à 19:19, Vincent Tondellier via frnog  a écrit :

On jeudi 2 mai 2024 19 h 04 min 32 s CEST, Philippe ASTIER via frnog wrote:
...

- sur la partie « split-tuneling », je ne vois pas trop le rapport.

Aucun, c'est la description du bug de David en SSL qui y ressemble

Ce que je trouve désolant, c’est que quand le client qui se connecte est sur 
n’importe quel autre réseau, avec ou sans IPv6, ou chez Free / FreePro, ben ça 
juste fonctionne sans aucun souci.
Donc je veux bien qu’il y ait aussi un bug qui traine chez Forti, mais  il n’y 
a que chez Orange (offre Orange Pro) que ça semble se déclencher, et c’est 
pénible.

C'est ce que je dis, il y a un truc sur l'IPv4 (uniquement) chez orange 
(uniquement) qui bloque l'udp et/ou l'esp, comme un proxy tcp only.
C'est en tout cas ce que je constate.
Activer ou désactiver l'IPv6 d'un coté seulement n'y changera rien.

Vincent.


Le 2 mai 2024 à 15:15, Vincent Tondellier via frnog  a écrit :
On jeudi 2 mai 2024 14 h 54 min 53 s CEST, David Ponzone wrote:
On doit pas parler du même problème.
Celui auquel je pense doit dater de 2021, concerne que SSL/Forticlient à 
priori, et se déclenche quand le client a accès à IPv6 alors que le serveur 
n’est pas dispo en IPv6.
Je ne connais pas fortinet, mais la description ressemble a un problème de 
split tunneling.
Cependant, Philippe parlait d'un problème avec IKEv2, pas avec SSL/ppp.
« A good IPv6 is a disabled one ».
Sans vouloir nourrir le troll, sur les réseaux mobiles, l'IPv4 est la plupart 
du temps cassé (CGNAT, DNS64 et autre) pour autre chose que du web simple.
IPv6, lui, fonctionne correctement.
Vincent.
...
---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/




---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

Désolé de ne pas être revenus vers vous avant ! Après-midi chargée et 
impossible d’avoir le client pour test avant demain.

Alors, je confirme :

- les clients se connectent en IPSec (IKEv1 ou v2, a priori, ça fait pareil) 
sur un FQDN IPv4-only,
- les Forti sont exclusivement en IPv4 (eh oui, vous pourrez me troller, je 
suis un fervent défenseur d’IPv6, mais pas dans ce cas ;p )
- les Forti sont sur la branche 7.2 pour le moment.

- Je n’ai pas encore pu toucher à leurs réglages d’APN, que je peux contrôler 
par un profil de configuration, y compris la version, v4 vs v6. (David, Apple 
Configurator, ça existe encore, mais on n’y touche plus depuis un moment, c’est 
trop basique)
On a les réglages à utiliser chez Orange ? 

- sur la partie « split-tuneling », je ne vois pas trop le rapport. Le tunnel 
s’établit, et tombe quasi immédiatement, uniquement via le réseau data d’Orange 
Pro. Par n’importe quel autre réseau qu’on a pu tester, ça fonctionne. 
- j’avoue que le coup de l’IP à la place du FQDN, ça coûte pas cher à tester, 
mais ça me choque ! 

- IPv6 n’est pas désactivable sur iOS. On peut le désactiver manuellement sur 
un SSID donné en Wifi ou une connexion Ethernet, mais pas de manière générale, 
et pas en cellulaire. 

Ce que je trouve désolant, c’est que quand le client qui se connecte est sur 
n’importe quel autre réseau, avec ou sans IPv6, ou chez Free / FreePro, ben ça 
juste fonctionne sans aucun souci.
Donc je veux bien qu’il y ait aussi un bug qui traine chez Forti, mais  il n’y 
a que chez Orange (offre Orange Pro) que ça semble se déclencher, et c’est 
pénible.



> Le 2 mai 2024 à 15:15, Vincent Tondellier via frnog  a écrit 
> :
> 
> On jeudi 2 mai 2024 14 h 54 min 53 s CEST, David Ponzone wrote:
>> On doit pas parler du même problème.
>> Celui auquel je pense doit dater de 2021, concerne que SSL/Forticlient à 
>> priori, et se déclenche quand le client a accès à IPv6 alors que le serveur 
>> n’est pas dispo en IPv6.
> 
> Je ne connais pas fortinet, mais la description ressemble a un problème de 
> split tunneling.
> 
> Cependant, Philippe parlait d'un problème avec IKEv2, pas avec SSL/ppp.
> 
>> « A good IPv6 is a disabled one ».
> 
> Sans vouloir nourrir le troll, sur les réseaux mobiles, l'IPv4 est la plupart 
> du temps cassé (CGNAT, DNS64 et autre) pour autre chose que du web simple.
> IPv6, lui, fonctionne correctement.
> 
> Vincent.
> 
>> 
>>> Le 2 mai 2024 à 14:46, Vincent Tondellier  a 
>>> écrit :
>>> Bonjour,
>>> On jeudi 2 mai 2024 12 h 56 min 30 s CEST, David Ponzone wrote: ...
>> 
>> 
>> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

OK, why not, on va faire ça sur le Mac, pas possible sur iOS.

(Chez Free, pas besoin de désactiver IPv6 en tout cas.)


Et pour la MTU, Ludovic, moi je veux bien…. Mais de quel côté ? Et puis le PMTU 
il est sensé être négocié proprement, je n’ai jamais eu à le faire sur aucun 
tunnel VPN.


Ce qui me choque, c’est que le seul fait de passer par Orange Mobile casse le 
fonctionnement d’un VPN alors qu’aucune des deux extrémités n’a changé sa 
configuration.



> Le 2 mai 2024 à 12:56, David Ponzone  a écrit :
> 
> Désactive IPv6 sur le client pour voir.
> 
> David
> 
>> Le 2 mai 2024 à 12:48, Philippe ASTIER via frnog  a écrit :
>> 
>> Salut à tous !
>> 
>> Je rencontre un souci très pénible.
>> 
>> J’ai depuis plus de dix ans plusieurs clients avec des sites distants et des 
>> Fortigate. Lignes fibres pour la plupart aujourd'hui, chez Orange Pro, Free, 
>> FreePro, SFR, Colt, Unyc, peu importe. J’ai des tunnels IPSec entre les 
>> sites distants sans aucun souci, fiables, ça monte très vite en IKEv2.
>> La plupart ont aussi un accès via leurs mobiles ou ordinateurs. SSL, IPSec, 
>> clients Forti selon les cas, mais pas eu beaucoup de soucis.
>> 
>> Depuis quelques mois (dur à retracer), chez un seul client, impossible de 
>> monter un tunnel IPSec via iOS ou macOS quand ils sont en 4G/5G (sur le 
>> device ou en partage de connexion).
>> Avec la même configuration, la connexion en wifi/ethernet depuis n’importe 
>> quel autre opérateur fonctionne sans souci. J’ai essayé via Free et FreePro 
>> mobiles, aucun problème, le tunnel est établie en 150 ms à peine.
>> 
>> Sur Orange Pro Mobile, la négociation des phases 1 et 2 semble se passer 
>> normalement, puis j’ai quasi dans la foulée un message du type «  recv 
>> ISAKMP SA delete » dans les logs de debug du Forti, et le tunnel ne monte 
>> pas.
>> 
>> 
>> Comme je viens de manger du log de debug depuis des jours en m’arrachant la 
>> tête, je me suis dit que soumettre ça à la brillante sagacité de la liste 
>> pourrait me donner des pistes…
>> Any idea ?
>> 
>> 
>> (PS: oui, dans ce cas précis, on envisage le VPN SSL, voire même on est en 
>> train de mettre une solution ZTNA basée sur Wireguard, mais si ça pouvait 
>> juste marcher comme chez les autres opérateurs, ça me soulagerait des 
>> plaintes récurrentes et justifiées du client)
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

Salut à tous !

Je rencontre un souci très pénible.

J’ai depuis plus de dix ans plusieurs clients avec des sites distants et des 
Fortigate. Lignes fibres pour la plupart aujourd'hui, chez Orange Pro, Free, 
FreePro, SFR, Colt, Unyc, peu importe. J’ai des tunnels IPSec entre les sites 
distants sans aucun souci, fiables, ça monte très vite en IKEv2.
La plupart ont aussi un accès via leurs mobiles ou ordinateurs. SSL, IPSec, 
clients Forti selon les cas, mais pas eu beaucoup de soucis.

Depuis quelques mois (dur à retracer), chez un seul client, impossible de 
monter un tunnel IPSec via iOS ou macOS quand ils sont en 4G/5G (sur le device 
ou en partage de connexion).
Avec la même configuration, la connexion en wifi/ethernet depuis n’importe quel 
autre opérateur fonctionne sans souci. J’ai essayé via Free et FreePro mobiles, 
aucun problème, le tunnel est établie en 150 ms à peine.

Sur Orange Pro Mobile, la négociation des phases 1 et 2 semble se passer 
normalement, puis j’ai quasi dans la foulée un message du type «  recv ISAKMP 
SA delete » dans les logs de debug du Forti, et le tunnel ne monte pas.


Comme je viens de manger du log de debug depuis des jours en m’arrachant la 
tête, je me suis dit que soumettre ça à la brillante sagacité de la liste 
pourrait me donner des pistes…
Any idea ?


(PS: oui, dans ce cas précis, on envisage le VPN SSL, voire même on est en 
train de mettre une solution ZTNA basée sur Wireguard, mais si ça pouvait juste 
marcher comme chez les autres opérateurs, ça me soulagerait des plaintes 
récurrentes et justifiées du client)
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Analyse de la 5G, première partie

[Philippe ASTIER via frnog]

Alors, il y a tout de même une grosse erreur d’interprétation statistique.

Confondre l’âge que certains réussissent à atteindre, et l’espérance de vie, 
qui est l’âge moyen que quelqu’un qui nait a l’espoir d’atteindre.
Et l’article de Nicolas montre justement qu’il y a tout juste un siècle, on 
n’avait guerre d’espoir de dépasser 40 ans. (Bien sûr et heureusement que 
certains arrivaient au double)

Donc non l’espérance de vie (pas l’âge maximal potentiel) a bien continué de 
progresser jusqu’à la fin du 20ème siècle inclus, ou là, on a assisté à la 
première diminution, liée effectivement aux problèmes d’hygiène de vie en 
général. Probablement le signe d’un excès de confiance dans ce que la médecine 
arriverait à résoudre aussi d’ailleurs, mais c’est un autre débat.

Le problème n’est pas la cause de la mortalité (en bas âge, d’épidémie, 
d’accident ou autre). Le graphique monte clairement que la population moyenne 
vit deux fois plus longtemps aujourd’hui.
Les raisons ? Oui, une grosse partie sur la baisse de la mortalité infantile, 
mais aussi les antibiotiques, l’hygiène, les vaccins, qui ont permis d’éviter 
des épidémies ou des maladies plus ou moins incurables ou très mortelles 
(tétanos, diphtérie, polio, et autres), de soigner plus de cancers (oui, 
parfois causés par d’autres inventions pas glorieuses) On le doit en grande 
partie au progrès scientifique, et ça appuie parfaitement mon propos de départ.

Après, chez les scientifiques comme partout, il y a des farfelus, des 
incompétents, des imposteurs médiatiques. Il y a ceux qui détournent les 
découvertes à des fins belliqueuses ou lucratives, et ça pourrit le monde.
Ce n’est pas la science ou les scientifiques le souci, c’est l’utilisation que 
d’autres en font. Ceux-là même ne veulent surtout pas partager le savoir.

"Science sans conscience n’est que ruine de l’âme", Rabelais, dans Gargantua, 
fin du XVème siècle….

Et là, j’avoue, Stéphane, que je suis bien d’accord. C’est parce que 
l’enseignement des sciences piétine depuis quelques décennies qu’on ne la 
comprend plus. Au moment où des défis de taille se pointent. C’est ballot.





Le 20 avr. 2024 à 11:57, Stéphane Rivière  a écrit :

Il me semble que - sans accident ni 'croquage' par un prédateur - l'espérance 
de vie d'une chasseur-cueilleur était effectivement à peu près la même 
qu'aujourd'hui, compte tenu de leur vie saine et de l'absence de polluants.

Mais une vie sans accident ni 'croquage', surtout quand on est un brave 
chasseur-cueilleur, était certainement réservé à des destins très chanceux :)

La réduction drastique et générale de l'espérance de vie est intervenue après, 
et semble avoir été liée à la sédentarisation et à l'agriculture, avec la 
cohabitation avec les animaux domestiques, transmissions de tout un tas de 
maladies et l'absence de la moindre hygiène élémentaire.

Nicolas évoque à juste titre la mortalité infantile, n'oublions pas non plus la 
mortalité maternelle : +- 50% à la première naissance, 33% à la seconde et 25% 
aux suivantes. Être mère, même entre la 1° et la 2° GM, c'est encore une 
loterie... Moins d'un siècle avant, on sacrifiait encore la mère pour tenter de 
sauver l'enfant. Et enfin un dernier point : le traitement de la douleur. Il 
fut un temps où... hormis les plantes médicinales... Puis ensuite, sous 
l'influence judéo-chrétienne, la douleur était sanctifiante... Désormais la 
douleur est traitée et ce n'est pas un détail.

Je suis personnellement heureux et étonné même de vivre aujourd'hui, avec 
beaucoup de science, de médecine et d'information. Le progrès fait rage dans 
ces matières et c'est une source infinie d'inspiration. Même l'IT est mille 
fois plus riche, ouverte et diverse. Et un jour, ipévésix triomphera et ce sera 
l'extase ;>

Vive 2024 au lieu de (n'allons pas si loin) 1974, où les chambres d'hôpitaux 
accueillaient 30 à 50 malades et mourants mélangés et où l'espérance de vie 
pour les hommes devait être aux alentours des 67 ans. Avec la retraite à 65, 
c'était un passage direct du chagrin à la boite en bois.

Alors certes, entre la coviderie d'hier et les temps guerriers d'aujourd'hui, 
il y a beaucoup de trouble dans la force, mais espérons que l'humanité se 
reprendra.

J'espère par contre que l'enseignement général s'améliorera et que l'on 
retrouveras le sens du caractère le plus important de la typographie, qui n'est 
ni une lettre ni un chiffre mais le point d'interrogation.

--
Stéphane Rivière
Ile d'Oléron - France


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Analyse de la 5G, première partie

[Philippe ASTIER via frnog]

Là je pense qu’un cap a été franchi.

Idiocracy dénonce clairement un système populiste qui fait disparaitre les 
intelligents au profit des "gens heureux » ou plutôt, qui sont flattés dans 
leur bonheur par des dirigeants douteux et stupides. (A la Trump quoi).

Sérieusement, sans connaissance, sans scientifique, on aurait le bonheur de 
vivre dans la misère jusqu’à 40 ans au mieux, comme il y a quelques siècles.

C’est facile, en 2024, de croire qu’on pourrait vivre sans les millénaires de 
connaissances accumulées. Il n’est pas question d’en haut ou d’en bas, mais de 
savoir collectif accumulé par l’humanité.
Je n’ai pas l’impression que dans les pays moins instruits, moins 
scientifiques, la population soit heureuse de crever de faim, souvent sous la 
joute d’un dictateur qui les maintient dans l’ignorance.

Je trouve ça d’autant plus hypocrite que toute la discussion parle de 
technologies qui ne sont développées QUE par des scientifiques qui ont accumulé 
des connaissances.
Sans physiciens, chimistes, mathématiciens, ou autres spécialités, pas 
d’internet, pas de radio, d’électronique, probablement même pas d’électricité.

Au passage, ce ne sont pas les savants qui gouvernent, mais quoi qu’on en dise 
des gens élus, acceptés ou tolérés par la plus grande partie de la population.
On peut remettre en cause le « système », la manière dont ces gens sont 
choisis, je suis prêt à l’entendre, il est même grand temps qu’il y ait débat, 
parce que le système politique est grippé, c’est certain.
Ce n’a jamais été des scientifiques qui ont fait l’organisation sociale.

Rejeter la science, la connaissance, c’est exactement ce que font tous les 
extrémistes, intégristes, populistes, sectes ou dictateurs, c’est le retour aux 
croyances, à l’âge de pierre.
Ils commencent par brûler les livres pour esclavagiser les populations.

C’est exactement ce que l’histoire nous apprend, et ce qu’idiocracy dénonce.


Ce n’est pas en rejetant la connaissance qu’on changera les choses, au 
contraire, c’est en la partageant au plus grand nombre.

C’est ce qu’on fait habituellement sur FrNOG il me semble. Partager notre 
expérience et notre connaissance.

Le 19 avr. 2024 à 11:28, Cédric Moro  a écrit :


Le 19/04/2024 à 09:30, Kévin CHAILLY a écrit :
Joyeux vendredi à tous!

Idiocracy ne se moque pas des gens simples, il se moque d'un système qui a
pour but de les créer ( "La fabrique d'idiots" )

Oh, j'avais pas compris :) Heureusement que les génialocrates sont là ;)

Idiocracy fait croire aux personnes qui regardent le film, que c'est bien de se 
foutre de la gueule des idiots et que le spectateur est assez supérieurement 
intelligent pour ne jamais faire partie des idiots, voir pour avoir la capacité 
de faire revenir au progressisme tout un système déliquescent grâce à ses 
connaissances éclairées. Beau miroir qui flatte l'égo des personnes diplômées 
qui aspirent à des responsabilités cadre. Pour y adhérer, il faut croire que 
l'intelligence vient d'en haut, de personnes techno éclairées, ce qui est la 
dérive anti-démocratique de notre époque.

Car on peut vivre très heureux dans des systèmes sociaux sans grande 
accumulation de connaissances. A l'inverse, nos sociétés très instruites, très 
scientifiques, ne savent elle pas qu'engendrer plus de solitude, de 
surveillance, de coercition, de dépression et de violence ? Le niveau 
d'instruction et même de réussite dans la technique n'a rien avoir avec 
l'intelligence. L'intelligence, et la fabrique de l'intelligence, c'est arriver 
vivre avec le maximum de personnes heureuses et cela ne viendra pas forcément 
d'en haut ; l'instruction ou la capacité déductive n'étant qu'un élément parmi 
d'autre de cette intelligence au niveau sociétal et probablement pas le plus 
important.



Une catastrophe ça ne commence pas à un mort, ça, c'est un mardi matin
normal, et c'est pour ça que les systèmes d'urgence ont été conçus,
répondre à des incidents quotidiens.

Merci, je bosse depuis plus de 25 ans dans la prévention des risques majeurs. 
Néanmoins, si vous perdez votre fille ou votre mère sur une urgence et que 
c'est la seule personne qui décède, vous réviserez probablement cette notion de 
catastrophe car votre vie sera bouleversée et probablement d'autres. Cette 
définition de catastrophe avec "un seul mort" est "humaine" et non "système". 
Il ne faut jamais la perdre de vue. Eviter 10 morts, ça commence déjà par 
éviter le 1er mort. Ensuite, il y a le libre arbitre de la personne qui prend 
des risques face à la mort et qui limite nécessairement (et peut-être même fort 
heureusement pour nos libertés) cet objectif de 0 mort.


Ajouter des éléments de communication en plus du RTC, c'est toujours une
bonne idée,
Voilà, c'est tout. Si cela marche un peu en plus des autres canaux, c'est bien.
on peut citer par exemple le système satellitaire "Bullitt" qui
est en prod et vise à fournir une communication en zone blanche uniquement
par message texte grâce à un matériel petit, consommant 

Re: [FRnOG] [TECH] 300Tbps par paire

[Philippe ASTIER via frnog]

Arf, my bad, j’ai lu trop vite parce que j’ai pris le thread en route entre 
deux réunions.

On est d’accord en fait. 
Mais c’est génial d’un point de vue marketing de valoriser un truc que les gens 
ne vont pas utiliser, et que du coup tu n’as même pas à surveiller et pour 
lequel tu ne garantis rien.
C’est mieux que d’avoir une course à la baisse de prix sur des tuyaux pleins.

Après l’avantage, c’est pour les petites structures de la tech qui avec une ou 
deux FTTH « low-cost » ont des bien beaux tuyaux pour pas cher. Ca permet des 
usages entre des petits sites ou vers des DC de manière très très fiable malgré 
tout. 
Prévoir quand même plus qu’une liaison et du backup au cas où.


Après, la presse « spécialisée »…. Ça reste la presse, pas des spécialistes 
hein. 



> Le 28 mars 2024 à 13:03, David Ponzone  a écrit :
> 
> Philippe,
> 
> Euh….
> 
> Si j’avais dit « 50mbps c’est assez pour un pro, même le siège social de 
> Total », je pense qu’on pourrait me virer de la liste.
> 
> Je crois que le débat était sur les offres FTTH des OCEN, à destination du 
> GP/Pro (pour un OCEN, le FTTH c’est l’offre référence pour un pro), dont le 
> marketing met en avant 2Gbps, voir 8Gbps, voir 10Gbps.
> Je ne crois pas que la boite de 300 personnes ou la boite qui fait de la 
> post-prod vidéo soient dans cette cible (si la boite de post-prod bosse sur 
> un FTTH, je pense que le patron est un gros radin, et je prends des chips et 
> attend avec impatience qu’il ait une coupure de 2 semaines).
> 
> L’entreprise moyenne française, elle fait moins de 10 personnes, et elle 
> bosse pas dans la tech (84% des entreprises ont 9 salariés ou moins).
> 
> D’ailleurs, c’était même pas un débat en fait. Juste un rappel que ça fait un 
> moment que le marketing met en avant des trucs qui servent à rien pour le 
> vendre (les forfaits illimités vers 120 pays, le forfait 5G avec 50Go de plus 
> pour 4€ de plus par mois, également appelées « techniques pour remonter son 
> ARPU quand on l’a trop baissé pour prendre des parts de marché »).
> Donc voilà, même la presse spécialisée en met une couche.
> « 4.5 million times faster », ça pète plus que « 6 times faster ».
> 
> Mais merci de confirmer que c’est dur de remplir un tuyau 10G chez Free avec 
> du vrai contenu ou des benchs, même en ayant que ça à faire de la journée :)
> C’était exactement mon propos, ils ont vendu du vent au Grand Public, comme 
> toujours.
> 
> David
> 
> 
>> Le 28 mars 2024 à 12:26, Philippe ASTIER  a 
>> écrit :
>> 
>> J’ai des clients qui font de la video conf à 1,5-4 Mb/s / client et qui sont 
>> 300 en simultané, faites le calcul. C’est même pas des qualités extrêmes.
>> Sur lequel on ajoute des transferts de gros documents, etc...
>> 
>> En plus il faut de la marge pour les autres usages, donc, oui, j’ai 
>> plusieurs clients qui ont du 500-600 Mb/s plusieurs heures par jour en 
>> continu, avec des pointes longues qui dépassent largement le 1 Gb/s, que ce 
>> soit up ou down.
>> 
>> On est en 2024...
>> 
>> 
>> Cela dit, pour le fun, j’ai secoué ma FreeBox Ultra. Dur d'atteindre la 
>> limite, parce que les serveurs de benchs ont des limites par flux TCP, IPv4 
>> vs IPv6, etc… j’ai du balancer du trafic de plusieurs machines, alors même 
>> que depuis cette même machine, aucun souci pour faire du 10 Gb/s en interne.
>> Mais je confirme qu’on peut bien agréger 7,5 Gb/s symétriques, ils ne 
>> mentent pas trop, même en pleine journée.
>> 
>> En fait c’est rassurant, les benchs ce n’est pas la vraie vie, juste une 
>> image d’un usage qui ne correspond pas à la réalité. 
>> 
>> Les CDN font clairement du rate limite par connexion de ce que je vois.
>> 
>>> Le 28 mars 2024 à 11:42, David Ponzone  a écrit :
>>> 
>>> 
 Le 28 mars 2024 à 11:35, Pierre Colombier via frnog  a 
 écrit :
 
 Ah non David, je suis pas d'accord.
 
 On sait bien que l'usage moyen est à moins de 50M. (même moins de 10M pour 
 la plupart des gens) Mais l'usage moyen n'est pas le chiffre le plus 
 pertinent.
 
 Le client, pro ou GP, il a besoin de >1G burst pendant moins de 0.5% du 
 temps et c'est cette pointe là qui lui donne l'impression de confort.
>>> 
>>> Ah, j’ai pas encore mesuré de crêtes à 1G chez mes clients pro.
>>> Je vois pas ce qui leur enverrait 1G (certainement pas MS Update).
>>> 0,5% du temps, c’est plutôt 100M.
>>> Donc on en revient à un besoin réel de 30-50M, avec crêtes à 100M (je parle 
>>> pas d’un pro avec 100 PC bien sûr, je parle d’un pro représentatif du tissu 
>>> français, donc moins de 10 personnes).
>>> 
>>> Ah si je sais ce que tu vois 0,5% du temps (donc environ 60 min/mois en 
>>> HO): c’est les speedtest :)
>>> 
 
 Après, c'est pas n'importe-qui qui a un PC avec de l’ethernet à plus de 
 1G. Mais pour un gamer, la moindre update fait plus de 10Go, si il peut 
 les avoir en moins d'une minute plutôt qu'en une heure, ça change 
 radicalement son ressenti.
 
>>> 
>>> Faut que le 

Re: [FRnOG] [TECH] 300Tbps par paire

[Philippe ASTIER via frnog]

J’ai des clients qui font de la video conf à 1,5-4 Mb/s / client et qui sont 
300 en simultané, faites le calcul. C’est même pas des qualités extrêmes.
Sur lequel on ajoute des transferts de gros documents, etc...

En plus il faut de la marge pour les autres usages, donc, oui, j’ai plusieurs 
clients qui ont du 500-600 Mb/s plusieurs heures par jour en continu, avec des 
pointes longues qui dépassent largement le 1 Gb/s, que ce soit up ou down.

On est en 2024...


Cela dit, pour le fun, j’ai secoué ma FreeBox Ultra. Dur d'atteindre la limite, 
parce que les serveurs de benchs ont des limites par flux TCP, IPv4 vs IPv6, 
etc… j’ai du balancer du trafic de plusieurs machines, alors même que depuis 
cette même machine, aucun souci pour faire du 10 Gb/s en interne.
Mais je confirme qu’on peut bien agréger 7,5 Gb/s symétriques, ils ne mentent 
pas trop, même en pleine journée.

En fait c’est rassurant, les benchs ce n’est pas la vraie vie, juste une image 
d’un usage qui ne correspond pas à la réalité. 

Les CDN font clairement du rate limite par connexion de ce que je vois.

> Le 28 mars 2024 à 11:42, David Ponzone  a écrit :
> 
> 
>> Le 28 mars 2024 à 11:35, Pierre Colombier via frnog  a 
>> écrit :
>> 
>> Ah non David, je suis pas d'accord.
>> 
>> On sait bien que l'usage moyen est à moins de 50M. (même moins de 10M pour 
>> la plupart des gens) Mais l'usage moyen n'est pas le chiffre le plus 
>> pertinent.
>> 
>> Le client, pro ou GP, il a besoin de >1G burst pendant moins de 0.5% du 
>> temps et c'est cette pointe là qui lui donne l'impression de confort.
> 
> Ah, j’ai pas encore mesuré de crêtes à 1G chez mes clients pro.
> Je vois pas ce qui leur enverrait 1G (certainement pas MS Update).
> 0,5% du temps, c’est plutôt 100M.
> Donc on en revient à un besoin réel de 30-50M, avec crêtes à 100M (je parle 
> pas d’un pro avec 100 PC bien sûr, je parle d’un pro représentatif du tissu 
> français, donc moins de 10 personnes).
> 
> Ah si je sais ce que tu vois 0,5% du temps (donc environ 60 min/mois en HO): 
> c’est les speedtest :)
> 
>> 
>> Après, c'est pas n'importe-qui qui a un PC avec de l’ethernet à plus de 1G. 
>> Mais pour un gamer, la moindre update fait plus de 10Go, si il peut les 
>> avoir en moins d'une minute plutôt qu'en une heure, ça change radicalement 
>> son ressenti.
>> 
> 
> Faut que le serveur en face suive.
> Je vais pas parler pour Steam, je connais pas, mais le PSN par exemple ne 
> suit carrément pas.
> Je suppose qu’ils utilisent tous des CDN, mais je suppose aussi qu’ils rate 
> limit quand même un peu.
> 
> David
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] IEEE 1588 Precision Time Protocol

[Philippe ASTIER via frnog]

Et malheureusement, les vendeurs de switchs enterrent le support de IEEE1588 
dans leurs docs, pas toujours facile à jour…

Au passage, Apple utilise aussi PTPv2 pour faire la synchronisation audio des 
appareils AirPlay 2 (exemple : une paire de HomePod), ou bien pour faire de la 
synchro audio.
Mais… pas de support officiel de PTP dans macOS, qui sort pourtant les trames 
quand vous faites du Airplay, un petit Wireshark voit les trames.

> Le 7 mars 2024 à 13:49, Noryungi  a écrit :
> 
> Je rajoute ma petite pièce :
> 
> PTP est utilisé pour partager une heure très précise (beaucoup plus précise
> que du NTP classique) entre une source de temps (horloge "atomique",
> synchro GNSS, par exemple) et un équipement donné.
> 
> Par contre tous les équipements situés entre l'horloge et la machine devant
> recevoir l'heure doivent supporter PTP.
> 
> Donc : horloge > switch > serveur par exemple. Tout dans cette chaîne doit
> supporter PTP pour que l'ensemble fonctionne.
> 
> C'est particulièrement utile quand tu as, par exemple, une opération x à
> effectuer à une heure y précise, avec une précision extrême.
> 
> Les autres réponses des membres de la liste sont aussi très bonnes.
> 
> N.
> 
> On Thu, Mar 7, 2024, 12:39 Pierre Colombier via frnog 
> wrote:
> 
>> Bonjour,
>> 
>> je suis à la recherche d'informations et de retours d'expériences
>> concernant la norme IEEE1588.
>> 
>> J'en ai découvert l'existence en repérant que le PHY Ethernet de mon SoC
>> disposait de lignes d'IO "sync_in"/"sync_out" qui semblent être en
>> relation avec ce protocole. mais sans beaucoup plus de précision sur
>> l'usage qui devrait ou pourrait en être fait.
>> 
>> L'accès à la norme elle-même est restreint par un paywall, et j'ai du
>> mal à me faire une vue d'ensemble.
>> 
>> Déjà je souhaiterais comprendre si c'est simplement un "gadget"
>> technologique ou si, au contraire, c'est largement adopté et utilisé
>> dans l'industrie.
>> 
>> Ensuite, pour la culture, j'aimerai comprendre à quel niveau on se
>> situe. Il y a des elements qui sont directement au niveau du PHY ce qui
>> suggère des couches très basse. Mais il y a un pendant logiciel plus
>> haut niveau...  C'est confus.
>> 
>> Bref, si quelqu'un peux m'expliquer ça en quelques phrases ou me donner
>> un lien vers une explication pas trop absconse, je suis preneur.
>> 
>> Merci d'avance.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Test de la robustesse de la liste

[Philippe ASTIER via frnog]

On a libéré combien de bande passante d’un coup ? Vous voyez quelque chose ??

> Le 5 mars 2024 à 17:15, Erwan David  a écrit :
> 
> Le 05/03/2024 à 17:13, David Ponzone a écrit :
>> On dirait :)
>> 
>> Ouf, je viens de voir ça, mais comme on arrive sur la page d’auth, j’ai cru 
>> que j’étais fait hacker.
>> 
>> Ca devient récurrent chez les leaders du monde connecté.
>> 
>> 
>>> Le 5 mars 2024 à 17:10, Stephane Bortzmeyer  a écrit :
>>> 
>>> Est-ce qu'elle marche quand Facebook et Instagram sont en panne ?
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> SI on a la page d'auth on sait déjà que c'est pas qu'ils ont coupé BGP comme 
> la dernière fois
> 
> -- 
> Erwan David
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Altitude/Covage/Kosc FTTH en folie...encore

[Philippe ASTIER via frnog]

Je ne sais pas si c’est lié, mais il y a eu une coupure électrique massive au 
centre de Nancy de 3 minutes vers 15h.

Même coup de pelleteuse ? :)

> Le 1 mars 2024 à 17:35, David Ponzone  a écrit :
> 
> Vous êtes prêts ? :)
> 
> 17h00 : Après les premières investigations de l'équipe sur place il s'agit de 
> coupures sur des câbles de grosse capacité (144FO et 288FO). Les équipes 
> recherchent le point d’impact.
> 
> Donc ils ont supposé une coupure énergie parce qu’ils ont perdu ouest et est.
> Donc ils ont pas d’accès OOB.
> Au secours.
> 
>> Le 1 mars 2024 à 16:51, Julien Issler  a écrit :
>> 
>> Kosc oui, Altitude/Rosace ça fonctionne
>> 
>> Et c'était le cas à chaque fois que Covage/Kosc a toussé ces derniers mois 
>> dans l'Est
>> 
>> Le 01/03/2024 à 16:48, Lilian RIGARD a écrit :
>>> Et je confirme que Kosc en FTTH c'est cassé.
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La belle boite de Pandore....

[Philippe ASTIER via frnog]

Je +1000.

Il y a quelques décennies, un admin ou un développeur, tout le monde avait au 
moins des notions des couches sous-jacentes. Le dev n’était peut-être pas un 
pro des requêtes ARP, mais il avait des idées de masques de sous-réseau.

J’ai été récemment frappé de voir des développeurs plutôt doués, travaillant 
sur des applications de big data sur des infrastructures Kubernetes (que je ne 
maitrise pas pour ma part, n’ayant pas pris le temps). En revanche, il ne 
s’était jamais demandé comment son fournisseur lui vendait ses services 
Kubernetes, ne connaissait même pas la notion d’Hyperviseur ou de cluster. Pour 
résumer, il n’avait aucune idée de ce qui faisait tourner son infra. Comme on 
était en train de déployer d’autres services sur un Proxmox, j’ai du reprendre 
les bases. Il comprenait, mais en vrai, jamais personne ne lui en avait parlé. 

Ca remet beaucoup de choses en perspective. Ce développeur achète du service « 
Kub » sans être en mesure de comprendre l’architecture de ce qu’il a acheté.


Les souci des « big 3 », c’est que tu peux avoir un service à disposition en 
quelques minutes et quelques clics à pas cher...
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] 240/4 strikes back

[Philippe ASTIER via frnog]

Merci je me sens moins seul. :)

Vous croyez vraiment un seul instant que les GAFAM ont perdu de l’argent en 
passant à IPv6 ?

Bien au contraire, ils ont investi dans l’avenir et économisent chaque jour un 
pognon monstre.

Google, Cloudflare ou Apple ont de magnifiques articles qui expliquent pourquoi 
et comment IPv6 dans leur réseau réduit la latence, les pertes de paquets, 
voire la consommation électrique, ça fait des années…
IPv6 leur offre une flexibilité et scalabilité sans commune mesure. IPv6, c’est 
comme du switching à l’échelle de la planète (je simplifie largement, quoi 
que…). 
Le NAT, c’est une latence inutile, et ça impose la torture de planifier des 
plages IP (ou de s’en procurer). Certains en vivent ? Tant mieux.

Autre exemple, quand Apple fournit des serveurs APNS pour les notifications 
push à 2 milliards de devices, plusieurs fois par seconde, vous croyez 
sincèrement que ça marcherait en IPv4 uniquement ? 
Si les plages privées en interne vous suffisent, alleluia. Mais Internet sans 
IPv6, ça n’existerait pas tel qu’on l’a aujourd’hui, faut retomber sur Terre.

Si vous pensez qu’on fait des backbones en Terabit/s avec de l’IPv4 et des 
trames de 1500 octets ou moins, il est temps de prendre votre retraite, merci 
d’avoir contribué aux glorieuses années où on cherchait à améliorer le NAT pour 
éviter de lire des RFCs sur IPv6.
Vous pensez que Starlink fonctionnerait en IPv4 ?

Franchement, faut pas s’étonner qu’on héberge nos données les plus sensibles 
sur Azure, et que nos plans nationaux de Cloud souverains tombent à l’eau… ou 
qu’on pense encore qu’un satellite géostationnaire va fournir de l’internet 
partout.
Musk (que je ne supporte pas) a commencé à dire que les numéros de téléphone, 
c’était un concept du passé. Il n’a pas tout à fait tort, c’est le début. Quand 
RCS sera interopérable iOS-Android-WhatsApp et que sais-je ? On veut contacter 
une personne ou un service, pas un numéro...
Vous avez vu que le fondateur de ChatGPT cherche à lever 5000 milliards de 
dollars pour l’IA ? 2 fois le PIB de la France…

C’est du délire, c’est éthiquement discutable, mais nous… on va former les 
dieux du NAT en IPv4. Cool. 
Et chouiner demain que les américains ont créé des industries ultra rentables 
et que nous…. Ben on sait pas faire, on n’a plus de constructeur, nos 
ingénieurs se sont barrés chez eux, et nos données sont hébergées aussi chez 
eux. 
Il faut se réveiller. 

Je suis navré de paraître énervé, mais je le suis. Moi aussi, j’ai appris IPv6 
après mon diplôme d’ingénieur, ça m’a pas toujours amusé, et j’ai l’âme d’un 
débutant, parce que je suis encore un néophyte. 
Mais je sais une chose, c’est qu’IPv4, c’est didactique, pratique pour aller 
vite à petite échelle, on en aura dans 20 ou 30 ans, mais ça ne permettra pas 
de construire l’avenir, c’est mort.


(PS: pour le post d’Emile. Les progiciels disparaissent au profit d’offres sur 
le Cloud. Les infrastructures on-prem s’effacent doucement, donc IPv6 est 
souvent très facile à faire dans les entreprises non-IT. J’ai accompagné des 
boites de plus de 3000 personnes avec des dizaines de sites dans le monde. On a 
viré les VPN, toute l’infra on-prem, leur dédiés en datacenters. Ils sont 100% 
Cloud, les sites sont juste des cyber-cafés avec des infrastructures un peu 
plus sécurisées. IPv4 ? On s’en fout, au contraire, c’est plus lent pour 
accéder aux applis Cloud…. CQFD les économies sont énormes, la flexibilité 
totale)


> Le 12 févr. 2024 à 21:35, Léo El Amri via frnog  a écrit :
> 
> Merci Philippe de rectifier les âneries qui ont été dites. À chaque fois 
> qu'on parle d'IPv6 c'est pareil : "l'IPv6 fait pas ceci que l'IPv4 fait", "le 
> protocole ne supporte pas telle configuration", "ouïn ouïn mon routeur 
> clic-clic ne supporte pas ce que je veux faire, c'est de la faute à IPv6".
> 
> Les gars, vous faites vraiment de l'Internet ?
> 
> 
> 
> Maximus nous dit:
> > Dans notre cas, y’a 1 gros problème pour passer en IPv6
> > Sur le site on a 2 opérateurs, chacun donne 1 /48.
> > Comment je fait pour adresser ?
> >
> > En IPv4, suivant l’accès internet utilisé, ça sera naté par l’IP de 
> > l’interface utilisé pour soritr.
> 
> Et en IPv6 tu choisirais un préfixe ULA pour ton réseau interne et tu 
> utiliserais NPTv6 en bordure.
> 
> IPv6 n'est pas moins bien qu'IPv4 sur ce point.
> 
> Maximus nous dit:
> > Mais en IPv6, si j’adresse avec le /48 de l’opérateur 1, comment je fais 
> > pour sortir par l’opérateur 2 ?
> > Du nat ?
> 
> Depuis quand le choix du WAN dépend de l'adresse IP de l'hôte source ?
> 
> Si dans ta configuration multi-WAN tu as choisi de déléguer le préfixe 
> fournit par un de tes fournisseurs d'accès, alors oui tu vas devoir NAT. Tu 
> peux NAT 1:1 ou bien choisir une configuration plus IPv4-esque. Libre à toi 
> de te tirer une balle dans le pied si tu le souhaite.
> 
> Sur ce point IPv6 est pareil qu'IPv4.
> 
> Maximus nous dit:
> > Oh le nat évoqué en IPv6, de l’urticaire se déclenche 

Re: [FRnOG] [MISC] 240/4 strikes back

[Philippe ASTIER via frnog]

Bon, faut quand même arrêter un peu les bêtises.

Si vous êtes convaincus qu’on ne sait pas faire du multi-WAN en IPv6, qu’il 
faut absolument du NAT ou du DHCP, alors oui… vous n’avez pas encore tout suivi 
en IPv6. Bref. (Et Fortinet fait très bien tout ce qu’il faut en la matière). 
Question d’apprentissage, et je conçois qu’il faut du temps.

Qu’on rechigne à déployer IPv4 pour des besoins internes, je peux le concevoir, 
il n’y a pas forcément d’urgence, on l’a concédé dans la discussion.
Et encore, il y a des entreprises avec plusieurs centaines de milliers de 
devices pour lesquelles IPv6 devient plus simple que v4.

De là à dire qu’IPv6 est un « fiasco », c’est juste n’importe quoi.

Les fournisseurs de contenu et de service dans le Cloud fournissent leur 
service en IPv6 et l'utilisent en interne.
Tous les OS modernes, clients ou serveurs, supportent IPv6 depuis longtemps.
Tous les fournisseurs d’équipements réseau d’entreprise supportent aussi IPv6, 
sinon sincèrement, faut penser à changer.

Les SI des entreprises, quand elles se tournent vers le Cloud (et ça 
s’accélère), deviennent naturellement accessibles en IPv6.

Quasiment la moitié du trafic vers Google (voir > 75% en France) dans le monde 
se fait en IPv6, quel fiasco.
Cela représente une latence réduite de 10 ms en moyenne pour l'utilisateur 
final, 20 ms en France. Quel fiasco.
100% des opérateurs mobiles français en IPv6, quel fiasco.
L’explosion de tous les microservices va rendre la vide dure à IPv4….

« IPv6 existe encore »  Non, mais vraiment ?
Je ne sais pas à quel rythme et jusqu’où ira l’adoption d’IPv6, mais faut être 
clair, plus de la moitié d’internet repose sur IPv6 (chez ceux qui hébergent et 
connectent internet, c’est devenu vital et ça passe avant IPv4), il n’y a 
aucune chance qu’il disparaisse, strictement aucune.
(Au passage, je ne suis pas certain qu’IPv4 disparaisse non plus de si tôt…)

On a commis deux erreurs avec IPv6 :
- faire croire que la seule motivation était la disparition des IPv4. Même si 
c'était un des moteurs, on sait que c’est faux.
- faire croire qu’il y aurait une « bascule ». C’est irréaliste, parce qu’il y 
a trop d’historiques impliqués.

Après, je suis certain qu’il y a encore des serveurs Netware à droite à gauche… 
et plein de gens prêt à dire que c’était mieux qu’IPv4.

L’avenir n’appartient plus à IPv4, mais on en aura encore dans plus de 20 ans.

Le 12 févr. 2024 à 19:46, Jérôme Marteaux  a écrit :

Le 12/02/2024 à 18:42, David Ponzone a écrit :
Ben bien sûr que tu peux faire du NAT quand tu failover sur l’opérateur 2.
C’est ce qu’on appelle une « dégradation » acceptable le temps de l’incident.
Ou sinon, tu fais en sorte que:
-en temps normal, tous les PC obtiennent leur IP en DHCPv6 (ou autre, y a 2 ou 
3 moyens non ? *grin*) du /48 de l’opérateur 1
-en failover, tous les PC ont un renew de leur IP dans le /48 de l’opérateur 2
Si IPv6 sait pas faire ça, c’est que c’est pas fini comme produit.
Tu t’en sors quand même en utilisant des leases très courtes.

Tu pointe les cas bien moisis d'ipv6, en plus d'être incompatible ipv6 ne copie 
pas les modes de fonctionnement bien compris et efficaces d'ipv4.
Pour adresser un périphérique il y a n méthodes possibles dont 1 seule qui 
ressemble à ipv4: DHCPv6.
Côté ISP l'adressage des CPE c'est carrément différent, rien n'est transposable:
- le mec qui avait compris ipv4 peut tout ré-apprendre;
- l'équipementier qui avait implémenté ipv4 peut tout refaire;
- le SI qui savait gérer ipv4 peut tout refaire.
En général on essaye de valoriser l'acquis pour progresser, il n'y a pas eu 
cette réflexion sur IPv6, ça ne m'étonne pas qu'IPv6 soit un échec.


La seule réussite d'IPv6 c'est dans le mobile et à mon sens pour une raison 
économique:
- IPv4 a besoin de CGN, ça coûte;
- IPv6 (grâce aux hébergeu^W GAFAM, merci la population à 99% d'eyeball grand 
public) le coût de DNS64 est bien moins cher que CGN.



IPv6 a coûté beaucoup d'argent, mais à dû représenter x point de marge en plus 
pour les SSII/ESN et les équipementiers qui ont vendu du bonhomme et des 
nouvelles boboîtes et doit bei représenter quelques ETP.

Mais pour au final quelle valeur ajoutée ? Est-ce que ça a servi à quelque 
chose qu'IPv4 ne permettait pas ?
Que d'énergie déployée pour ... rien ! Alors que cette énergie aurait pu servir 
à autre chose.

IPv6 existe encore car les opérateurs, intégrateurs, équipementiers ont pu 
rogner x point de marge pour être "compatible". Si le secteur était moins 
porteur avec des marges plus faible je pense qu'IPv6 aurait été déclaré inapte 
et serait un échec, et on serait passé à autre chose !


En France on a fait l'EPR (merci à Siemens et aux allemands au passage), mais 
l'IPv6 c'est pas mal non plus comme échec, sur le papier c'est très beau, mais 
difficile à construire et une fois construit il faut le maintenir.

La bascule IPv4 => IPv6 a combien d'années de retard ? En 2024 on est à quel 
facteur entre le budget initial et le budget 

Re: [FRnOG] [MISC] 240/4 strikes back

[Philippe ASTIER via frnog]

Ah ça…. IPv6 doit faire partie du cahier des charges. Bon sang, c’est trivial 
pour un développeur normalement bon.


Le 12/02/2024 à 11:12, Pierre Colombier via frnog a écrit :
Par contre, la dual-stack, c'est juste 2x plus de boulot à maintenir (et au 
moins 3x plus à monitorer) pour rien.

Sans aucune considération philosophique, idéologique ou dogmatique, voici ma 
feinte à deux balles du jour :

J'essaye d'installer un serveur RustDesk (un clone de TeamViewer, open-source 
et auto-hébergeable, qui semble avoir une bonne cote) :
- Le logiciel ne permet pas de choisir sur quelle interface réseau il va se 
"binder"
- Le logiciel utilise des ports TCP et UDP pour son fonctionnement. Sur une 
machine Ubuntu avec install par défaut (une IPv4 et une IPv6); concernant TCP, 
il écoute uniquement en tcp6; pour l'UDP, il écoute bien sur les deux (udp4 et 
udp6)
- Le truc drôle, c'est que, sur une autre VM Debian 12, avec IPv6 explicitement 
désactivé au niveau de sysctl.conf, il écoute quand même en tcp6 :-D Et, bien 
sûr, il n'écoute pas du tout en tcp4 :-D Magique !

On est bien d'accord que le problème vient du soft :-) Et qu'un soft bien conçu 
devrait théoriquement permettre, dans ses paramètres de configuration, de 
spécifier exactement sur quelle interface et sur quelle IP il doit se binder 
:-) Et on est ici sur un gros projet open-source, avec une boite commerciale 
derrière, pas sur un fabricant d'alarmes ou de portails électriques qui a 
acheté un module réseau sur AliExpress :-)

Donc, je peux comprendre qu'il y ait des gens qui trouvent des intérêts vitaux 
à IPv6, et même des gens qui l'apprécient :-) Pas moi :-)



---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] 240/4 strikes back

[Philippe ASTIER via frnog]

Excellent :)

Merci d’avoir fouiné, ça fait preuve d’un peu de créativité qui me fait 
sincèrement plaisir.
Mon site web n’est à l’heure qu’il est pas exposé, ni en IPv4 d’ailleurs,  mais 
en l’occurrence, le NGINX qui est derrière est bien totalement accessible en 
IPv6 depuis le premier jour, mon dév et moi sommes ultra alignés là-dessus, 
nous n’ouvrons jamais de service qui ne soit pas au moins en IPv6 et 
éventuellement en IPv4.. :)

Sur le profilage, navré, mais là c’est faire preuve d’une naïveté extrême. On 
laisse tellement de traces que l’adresse IP, quelle qu’elle soit, est une 
broutille qui ne fait plus peur à personne.
Pour vous faire peur, je vous recommande d’essayer https://amiunique.org/. Vous 
comprendrez que vous êtes fingerprinté par tellement d’autres critères…


Le 12 févr. 2024 à 17:47, Laurent Barme <5...@barme.fr> a écrit :


Le 12/02/2024 à 09:27, Philippe ASTIER via frnog a écrit :

Perso, ni chez moi ni chez mes clients, je ne déploie quoi que ce soit qui ne 
sache pas ce qu’est IPv6.


C'est très bien. Mais en attendant, tes futurs clients vont avoir du mal à se 
renseigner sur les services proposés par ta société :

# wget https://www.astier-consulting.fr
--2024-02-12 17:06:26--  https://www.astier-consulting.fr/
Resolving www.astier-consulting.fr (www.astier-consulting.fr)... 
2606:4700:3108::ac42:2863, 2606:4700:3108::ac42:2b9d, 172.66.40.99, ...
Connecting to www.astier-consulting.fr 
(www.astier-consulting.fr)|2606:4700:3108::ac42:2863|:443... connected.
HTTP request sent, awaiting response... 526
2024-02-12 17:06:26 ERROR 526: (no description).

Rien de personnel bien sûr mais je saisie juste cette opportunité d'illustrer 
que l'IPv6 ne fait pas tout :-)

Pour autant que je comprenne, l'IPv6 apporte certes une augmentation 
considérable du nombre d'adresses IP (et la fin des NAT) mais embarque aussi la 
possibilité d'un "profilage" (ou contrôle) beaucoup plus précis des usages 
(justement par la fin des NAT). Je me demande si ce ne serait pas cette 
deuxième raison la principale motivation présentée sous couvert de la première…

Je précise. En IPv4, l'utilisateur est planqué derrière une IP publique avec un 
port éphémère qui permet de faire le lien avec son IP locale en pratique 
inconnue de l'extérieur alors qu'en IPv6, on a une visibilité précise du poste 
de l'utilisateur (ou de l'équipement ou de l'objet connecté).

Sinon, aujourd'hui, l'un de mes serveurs qui représente un intérêt totalement 
dérisoire, bloque plus de 58000 IPv4 de pirates. Je n'ose pas imaginer ce que 
ce sera quand il devra filtrer les IPv6 lorsque les IPv4 auront disparues !

Pour ma part, je passerai à l'IPv6 quand ce sera nécessaire (mais ce n'est pas 
moi qui décide).




---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] 240/4 strikes back

[Philippe ASTIER via frnog]

> Le 12/02/2024 à 11:12, Pierre Colombier via frnog a écrit :
>> Je ne sais pas ce que vous en pensez mais ipv6 only, moi je veux bien ! 
>> C'est quand on veux !
>> Par contre, la dual-stack, c'est juste 2x plus de boulot à maintenir (et au 
>> moins 3x plus à monitorer) pour rien.
>> A partir du moment où on est obligé de maintenir le v4, avoir du v6 en plus 
>> ne présente quasiment aucun intérêt.
> 
> Et c'est sans doute là la faiblesse d'ipv6, ça n'apporte quasiment rien de ce 
> qu'ipv4 sait faire.

Non, c’est sûr…. IPv6 n’apporte rien. Pas de simplification du réseau, pas de 
suppression du NAT, pas un routage plus rapide, rien, nada. 

> En fait, ce sont précisément les appareils ou l'adressage direct d'ipv6 
> serait intéressant qui le supportent peu ou mal, à commencer par la VOIP.
>> Si la VOIP pouvait être en v6, mais qu'est-ce que ça serait plus simple !!!
>> Parce-que les empilages de traversées de NAT ou de firewall, c'est sans 
>> doute largement mieux qu'il y a 10 ans mais ça reste quand même bien bien 
>> foireux selon les combinaisons de matériel ou d'opérateur.
> 
> L'encapsulation est le métier de base des opérateurs, alors opérer du 
> firewall c'est juste un niveau au-dessus, ils pourront survivre à cette 
> "évolution".
> 
>> Je pense que la solution serait que les opérateurs de backbone/tier1 se 
>> mettent d'accord pour définir et annoncer une date d'extinction du routage 
>> ipv4 global.
>> 
> 
> Personne ne peut entendre ça. A mon avis, les 2 seuls éléments qui feront 
> "éteindre" ipv4 sont:
> - que plus personne ne veut de transit ipv4 (ce n'est pas prêt d'arriver);
> - que router de l'ipv4 devienne trop cher par rapport à ipv6 et je ne vois 
> pas comment ça pourrait techniquement être le cas.

Les GAFAM, CloudFlare, leurs CDN et tous leurs services sont en IPv6. Certains 
« petits » opérateurs comme Free n’ont a priori plus que de l’IPv6 sur leur 
backbone et jusqu’au client sur la fibre.
Ca m’étonnerait qu’ils fonctionnent entre eux avec du transit IPv4. 

En quoi router IPv4 est moins cher qu’en v6 ??? 
Le thread a justement commencé par parler de la monétisation des IPv4, ce qui 
est fondamentalement la meilleure raison de s’en éloigner.

En fait, je crois qu’on est tous d’accord.

Il y a techniquement moins d’urgence à passer en IPv6 que ce qui a été prétendu 
pour passer en v6 (ie: la grande peur de la fin des IPv4).
Passer en v6 en interne dans les entreprises demande un effort qui ne rapporte 
rien à court terme dans les TPE/PME au moins, et chacun y fait bien ce qu’il 
veut.

En parallèle, les gros fournisseurs de contenu, le grand public sans même le 
savoir, sont DEJA passés en IPv6…
Les incitations réglementaires continuent à aider.

Personnellement, je pense juste qu’étre prêt, et déployer quand ça a du sens, 
c’est juste se préparer à l’avenir.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] 240/4 strikes back

[Philippe ASTIER via frnog]

"Obligatoirement" ? C'est une contrainte technique ? Je ne connais pas très 
bien la pile 3GPP, mais j'imaginais ça bien moins corrélé à l'IP que ça.

Pas technique, réglementaire. Cela dit, la stack 3GPP a poussé le support du 
dual-stack assez « tôt »  (plus de 10 ans maintenant), dès la 4G, avec une 
incitation plus forte en 5G.

L’ARCEP, le 21 novembre 2019, a publié l’obligation pour les opérateurs de 
réseau mobile de rendre leur réseau IPv6 compatibles avant le 31 décembre 2020. 
(S’ils voulaient faire de la 5G dans la bande 3,4-3,8 GHz).
Ils s’y sont tous conformés. Après, l’adoption réelle par les clients n’est 
évidemment pas allée aussi vite, nécessitant parfois une activation « manuelle 
».
Free par exemple a trainé la patte, mais depuis presque un an maximum, IPv6 est 
activé par défaut.

D’après les stats qu’on trouve à droite à gauche, entre 75 et 95% des mobiles 
français ont IPv6 actif.

Les grands faiseurs (nationaux ou internationaux) n'y sont pas pour 
grand-chose, et les technos de passerelle (6to4, dns64 et affiliées) ne 
suffisent pas :
- La VoIP : les devices (fabricants) et les trunks (opérateurs)
- les copieurs, imprimantes, scanners et autres prestataires qui les pilotent
- les logiciels métiers où les liaisons entre applications sont définies dans 
des champs texte ne supportant que l'IPv4, voire même ne supportant pas les 
noms DNS.
- les devices : switchs, points d'accès, caméras vidéos, portiers, domotique 
d'entreprise, etc.

Tous ces gens ne bougeront un neurone que lorsque les grands auront bougés. 
Vive l'inertie technologique.

Ben il va falloir choisir. Les téléphones SIP Cisco supportent IPv6 depuis plus 
de dix ans (15 ?), toutes les imprimantes de marques sérieuses supportent IPv6, 
les logiciels « métier »… ça, c’est plein de sceptiques qui maitrisent parfois 
à peine IPv4.

Les devices ? Routeurs, switch ou points d’accès qui ne supporteraient pas IPv6 
mériteraient un passage immédiat au recyclage.
La domotique, c’est marrant, parce que justement, vu le nombre de devices 
potentiellement à déployer, IPv6 aurait un intérêt énorme. Oui, c’est à la 
traine, hélas.

Cela dit, les protocoles HomeKit, Thread et Matter sont BASES sur IPv6, qu’ils 
rendent obligatoire.

Sérieusement, prenez un Wireshark, et regardes ce qui passe déjà sur vos réseau 
en IPv6, vous seriez surpris (enfin, sauf si plutôt que de chercher à 
comprendre l’impact et vivre avec, vous avez fait l’effort de filtrer IPv6 
autant que possible hein).


Moi, tout le fond de mon inquiétude, c’est de continuer à déployer aujourd’hui 
des devices qui n’entendent pas IPv6, parce que c’est sur 5 ou 25 ans, ça 
progresse.
Refuser de « prendre date » et de se former, ça veut dire qu’un jour, le 
changement sera brutal, non choisi, et/ou nécessitera de changer du matériel.

Perso, ni chez moi ni chez mes clients, je ne déploie quoi que ce soit qui ne 
sache pas ce qu’est IPv6.

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] 240/4 strikes back

[Philippe ASTIER via frnog]

Tout opérateur 5G est obligatoirement en IPv6, et ça inclut Free.

Comme Netflix d’ailleurs totalement disponible en v6 depuis des années.

Evidemment, pour le savoir, encore faut-il ne pas avoir banni IPv6 pour des 
raisons idéologiques.

L’histoire du 240/4, c’est intéressant.
Autant je suis conscient qu’IPv4 durera longtemps encore, autant changer les 
règles sur les IP publiques / privées en v4, ça frôle l’impossible, parce que 
beaucoup trop d’appareils ne pourront simplement pas être modifiés du tout.
On a tous beaucoup trop de devices dont la stack est figée dans des firmwares 
non upgradables.

Bref…..

Le 11 févr. 2024 à 19:31, Yann S. O.A.  a écrit :

La France bonne élève pour le coup. Il nous manque principalement SFR en
grand public fixe et Free en mobile il me semble ?

Après il y les entreprises...

O.Y.

Le dim. 11 févr. 2024, 16:07, GROS Jérôme  a écrit :

Un article en fr, sur le milliard qu'AWS ve se faire sur l'ipv4 :
https://www.lemondeinformatique.fr/actualites/lire-facturer-les-adresses-ipv4-un-business-fructueux-pour-aws-92886.html
S'il voulait vraiment "accélérer votre adoption d'IPv6", l'augmentation ne
serait pas aussi dérisoire...

Et tjs: https://www.google.com/intl/en/ipv6/statistics.html
Le 10/02/24 16:44, Radu-Adrian Feurdean a écrit :
On Sat, Feb 10, 2024, at 12:51, David Ponzone wrote:
Depuis le temps, je comprends pas que Netflix ait pas encore produit un
docu-série « What killed IPv6 ? » :)

Pour la diffuser "over IPv6" ? Ca serait intéressant :)


---
Liste de diffusion du FRnOG
http://www.frnog.org/


--
@++
jg.


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La belle boite de Pandore....

[Philippe ASTIER via frnog]

Et finalement, au bout du compte, qu’est-ce qu’ils ne savent pas faire les 
européens ?
La remontée légale des données stockées aux autorités américaines peut-être ???

Microsoft est bien une filiale d’une société américaine, non ? Vous croyez 
vraiment qu’ils échappent aux règles US ?

C’est très scandaleux….

Le 1 févr. 2024 à 15:29, clarinette  a écrit :

voici ce que j'ai pu lire sur Twitter:
Dans l’avis du jour de la @Cnil autorisant l’Etat à héberger nos donnés de
santé chez Microsoft, la Cnil dit déplorer que les prestataires européens
n’offrent pas de solutions équivalentes, se basant sur un rapport qui
l’affirme. Je rappelle que chez @clever_cloudFR comme chez tous les autres
nous n’avions même pas reçu jusqu’à très récemment de cahier des
charges détaillé (@waxzce m’en est témoin). L’Etat aurait pu, mais surtout
aurait du !, mettre en amont autour de la table les acteurs  et leur
dire “voici de quoi nous aurons besoin dans 2 ans, débrouillez-vous
ensemble , vous aurez xx millions d’euros de marché garanti si vous y
parvenez”. Au lieu de ça il s’est contenté de faire son marché, sans vision
industrielle, au profit de Microsoft.

On Thu, Feb 1, 2024 at 2:26 PM Sylvain Charron (LASOTEL) <
schar...@lasotel.fr> wrote:

Je voudrais bien lire l'analyse technique de la CNIL qui a servi à
conclure :

"Aucun prestataire potentiel" parmi les opérateurs de cloud français
ou européens "ne propose d'offre d'hébergement répondant aux exigences
techniques et fonctionnelles" du projet, constate la Cnil pour
justifier sa décision, s'appuyant sur une mission d'étude réalisée par
l'Etat.

Il faudrait également analyser le cahier des charges du projet pour
s'assurer que les exigences techniques et fonctionnelles sont réellement
légitime ou ne servirait pas uniquement à justifier le choix Microsoft.

+1 sur affligeant et honteux
+1 sur belle boite de Pandore

En espérant que des journalistes rebondissent sur ce projet "Health Data
Hub", datant de la période COVID.

Sylvain

Le 01/02/2024 à 15:08, Bertrand FRUCHET via frnog a écrit :
Bonjour la liste,

C'est affligeant et honteux !

Bertrand


Le 01/02/2024 à 14:08, David Ponzone a écrit :

https://www.bfmtv.com/tech/actualites/donnees-personnelles/la-cnil-autorise-le-stockage-de-donnees-de-l-assurance-maladie-chez-microsoft_AD-202401310452.html
<
https://www.bfmtv.com/tech/actualites/donnees-personnelles/la-cnil-autorise-le-stockage-de-donnees-de-l-assurance-maladie-chez-microsoft_AD-202401310452.html>



J’aime beaucoup le « temporaire ».


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/



--
Privacy and Data Protection - LLM
GDPR Compliance
Voted Privacy Hero of the Year
KingstonCognate Top 50 Global Experts
The information contained in this e-mail message is intended only for the
personal and confidential use of the recipient(s) named above. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are hereby
notified that you have received this document in error and that any review,
dissemination, distribution, or copying of this message is strictly
prohibited. If you have received this communication in error, please notify
us immediately by e-mail, and delete the original message.

---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Fin de l’IPv4 en République tchèque

[Philippe ASTIER via frnog]

En fait, à chaque fois que le débat IPv4 vs IPv6 revient, je pense qu’on oublie 
quelques facteurs.

Les infrastructures publiques vont nécessairement vers de l’IPv6, à cause du 
nombre de devices à connecter, du prix des IPv4, d’obligations normatives 
(coucou 5G) ou légales dans certains pays. C’est déjà très largement en marche, 
et tous les gros acteurs du marché (GAFAM, CDN) sont en dual-stack sur tous 
leurs services, voire imposer d’avoir au moins une compatibilité IPv6 (ex.: 
obligation du support d’IPv6 dans toute application de l’AppStore d’Apple, 
juste 2 milliers d’appareils).

Les infrastructures privées, où il n’y a pas de nécessité immédiate, et où les 
coûts du changement ou de support ne sont clairement pas une incitation à 
changer.


Donc qu’IPv6 vous plaise ou pas, ça progresse, pour le public.
Si vous ne voulez pas supporter ça en interne, faites comme vous voulez.

Pour ma part, je pense qu’il est grand temps de comprendre et de chercher à 
implanter IPv6 en interne pour ceux qui ne l’auraient pas encore fait, parce 
qu’un jour, un de vos VIP internes voudra accéder à un service externe IPv6 et 
vous aurez le choix entre le faire et votre job.

Vous en voulez une autre du même genre ? WPA3.
Obligatoire en Wifi 6E/7 pour exploiter la bande des 6 GHz, et incompatible 
avec le mode transitionnel… Ben on va avoir une jolie fracture numérique aussi 
entre les devices qui ne peuvent pas (hhh tout l’IoT en 2.4 GHz) et les 
devices modernes.


Un jour, faut savoir arrêter les vieilles technos. Mais IPv4 n’est pas une 
vieille techno avant longtemps.

Le 26 janv. 2024 à 16:00, Mickael MONSIEUR  a écrit 
:

Le ven. 26 janv. 2024 à 14:44, David Ponzone 
mailto:david.ponz...@gmail.com>> a écrit :

Je pense que la raison est claire:
-fin de la 2G/3G: intérêt financier
-fin cuivre: intérêt financier
-fin IPv4: rien à gagner, à part des emmerdes

rien à GAGNER à 40-60$/IPv4 ? euh.. c'est Vendredi mais quand même ;o)

Le 26 janv. 2024 à 14:37, Pierre-Henry Muller via frnog  a 
écrit :

Le dual stack ne me dérange pas du tout, on en fait sur tous nos clients depuis 
2010. Et je pense clairement que l'IPv4 sur les réseaux locaux va encore 
perdurer longtemps et finalement il est peut-être plus adapté que le v6 pour du 
local.

Le "malheureusement" est en direction de ceux : ARCOM, Etats, ayatollah qui 
prédisent la fin d'IPv4 ou qui ne veulent pas gérer de dual stack car ça 
implique double supervision. D'ailleurs on est en 2024 et on a toujours des 
liens ou services IPv6 qui tombent sans que personne ne s'en rendent compte.

Par contre pour la 2G/3G, cuivre là c'est pratiquement acté que ça va 
disparaître à l'inverse du POCSAG encore utilisé et pourtant plus vieux.


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Pb Wifi 5ghz

[Philippe ASTIER via frnog]

Dites voir, je crois qu’on oublie quelques points au lieu de tenter de perdre 
du temps à diagnostiquer un souci « wifi » .

- Le matériel n’est pas conforme aux normes françaises, il ne devrait pas être 
installé.
- Il utilise des credentials par défaut absolument scandaleux,
- le firmware est super douteux 
- le prestataire ne sait pas le faire fonctionner et ne comprend pas les 
risques de sécurité.

Donc, ça se remballe, on le rend au prestataire, et soit il fournit un truc 
sérieux, soit on change aussi le prestataire.
D’ailleurs je commencerai peut-être par ça ? :)

En plus, ce n’est pas au client de diagnostiquer et corriger les soucis du 
matériel vendu. 

Après, s’il est question de s’amuser, ça peut être marrant, mais le truc semble 
juste vraiment pourri à tous les étages.


> Le 6 oct. 2023 à 12:00, Filipe Gaspar  a écrit :
> 
> Pour résoudre ce problème, le plus rapide est de réaliser un site survey
> avec un outil pro genre ekahau + sidekick ou autre.
> 
> Après sur le canal 149 il ne doit pas y avoir grand chose..
> 
> Tu parles de grésillement mais la perte de paquet est plutôt caractérisée
> par des bruits de craquement ou bien des blancs quand c'est plus long. Tu
> maintiens qu'il s'agit de grésillement ?
> 
> Sinon la solution de tout remplacer est pas mal non plus.
> 
> Filipe
> 
> 
> Le ven. 6 oct. 2023 à 11:48, David Ponzone  a
> écrit :
> 
>> Ouais enfin, le radar météo, ça dure pas si je dis pas de bêtises.
>> Il peut y avoir le WIFI d’un voisin qui praline avec du matos non-CE aussi.
>> Un petit coup de WiFi-Scanner peut-être ?
>> 
>>> Le 6 oct. 2023 à 11:17, Olivier Varenne  a
>> écrit :
>>> 
 Si vraiment tu veux debug, y a pas grand chose qui peut perturber du
 5Ghz à part le WIFI existant, tu peux le couper pour vérifier ?
>>> 
>>> Il est peut être collé à un radar météo ?
>>> Ou meme peut être qu'il est DANS le radar météo 
>>> 
>>> 
>>> 
>>> Cordialement,
>>> 
>>> 
>>> 
>>> Olivier Varenne
>>> Président, R et développement
>>> T +33 (0)4 27 04 40 00 | ipconnect.fr
>>> 
>>> Suivez-nous !
>>> 
>>> 
>>> 
 -Message d'origine-
 De : frnog-requ...@frnog.org  De la part de
 David Ponzone
 Envoyé : vendredi 6 octobre 2023 10:45
 À : Ludo 
 Cc : frnog-tech 
 Objet : Re: [FRnOG] [TECH] Pb Wifi 5ghz
 
 Franchement, tu as envie de perdre du temps à comprendre pourquoi
 du mauvais matos chinois déconne ?
 Je comprends, c’est beaucoup moins cher que le bon matos (chinois ou
 autre), mais quand le presta démissionne du problème, ça m’inquiète.
 
 Si vraiment tu veux debug, y a pas grand chose qui peut perturber du
 5Ghz à part le WIFI existant, tu peux le couper pour vérifier ?
 
> Le 6 oct. 2023 à 10:08, Ludo  a écrit :
> 
> Bonjour la liste,
> 
> Je suis un fervent lecteur, mais je ne me suis jamais exprimé jusqu'à
> présent.
> 
> J'aimerai avoir vos avis sur un problème que je rencontre à $taf.
> 
> Un presta a été mandaté pour installer la salle de conférence
> (videoproj, écran, et micros sans fils) Le problème rencontré se situe
> au niveau des micros sans fils, ces derniers grésillent.
> 
> La techno employée est du wifi 5ghz, il y a 3 acteurs, une centrale,
> les micros, et un Access Point.
> L'AP est connecté à la centrale en rj45. Cette centrale alimente en
> POE l'AP.
> Les micros sont connectés en Wifi (5ghz) à l'AP.
> 
> Je pense que la "centrale" est une espèce de boitier de traitement
> audio
> (dsp) avec d'autres fonctionnalités.
> 
> Je RTFM du bouzin. Le SSID est masqué, mais il est indiqué dans la
 doc.
> Le mot de passe du network est "" (j'apprendrai plus tard
> qu'on ne peut le changer, ce dernier étant rentré en dur dans les
> micros) Je trouve aussi  l'IP de l'AP dans la doc, je me connecte.
> (admin/admin par
> défaut)
> 
> À ce stade, je commence déjà à me poser de sérieuses questions ...
> 
> La borne possède un firmware des années 90 et la moitié du
 firmware
> n'est pas traduit, il y a des boutons en chinois qui reste peu importe
> la langue sélectionnée.
> 
> Une fois connecté à la borne j'ai dans l'idée de changer les canaux,
> j'envoi un mail au presta, pour voir s' il n'existe pas un update de
> firmware, et échanger sur les canaux.
> En retour il me dit que non pas d'update et il me conseille le canal
> 149 
> 
> Je regarde sur la borne et effectivement il est possible de la régler
> sur le 149 en 5ghz, par contre impossible de régler le pays 
> 
> Ont-ils le droit de vendre ça en France ? (puissance d'émission > 25
> mw)
> 
> J'ai modifié tous les paramètres/canaux de ce foutu AP. Toujours
 pareil 
> 
> Je sais reproduire à 100% les "grésillements" qui sont en fait des
> pertes de paquets. Les "grésillements" se produisent aléatoirement
 

Re: [FRnOG] [TECH] FreeBox pro admin depuis le LAN

[Philippe ASTIER via frnog]

Ce qui fonctionne très bien, c’est de mettre ton propre routeur derrière la 
Freebox Pro. 
Tu feras ce que tu veux de ton DHCP (ou autre), et en cas de bascule, seule ton 
IP publique change.

> Le 29 sept. 2023 à 13:14, David Ponzone  a écrit :
> 
> Free, même Pro, ne va pas rentrer dans le marché du CPE configurable (donc 
> cassable) par le client.
> Leur marché, c’est le CPE avec un process industriel, que le client ne peut 
> pas défoncer, parce que ce même client ne paie pas assez cher pour imaginer 
> avoir un mec au support qui va corriger ses conneries, sachant que pendant ce 
> temps, ce même client va râler en criant partout que c’est intolérable cette 
> qualité de service déplorable, et qu’il comprend pas pourquoi y a pas un mec 
> qui vient lui apporter sous 1 heure un nouveau routeur en Aston Martin avec 
> un café.
> 
> Pour garder le contrôle, il vaut/faut généralement mieux mettre son matériel, 
> et oublier les box triple/quadruple/jesaispascombien-play.
> 
>> Le 29 sept. 2023 à 12:49, jehan procaccia INT  
>> a écrit :
>> 
>> Bonjour
>> 
>> est-il possible d'administrer une freebox Pro depuis le LAN ? (comme on le 
>> fait avec les freebox de particuliers, delta etc ... via  un acces 
>> https://192.168.1.254) ?
>> 
>> apparement seuls l'acces "SAAS"  sur https://pro.free.fr/account/#/ semble 
>> etre autorisé !?
>> 
>> c'est problematique quand l'uplink fibre est down et qu'on fonctionne sur le 
>> secours 4G , c'est alors le dhcp du boitier 4G qui fournit des IP aux 
>> clients dans un subnet different (250 sur le 3eme triplet) . J'aimerai 
>> pouvoir gerer le dhcp quand on est dans un etat degradé.
>> 
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Foudre

[Philippe ASTIER via frnog]

Dans les années 80-90, le CCETT à Lannion avait un bulletin technique assez 
intéressant, dont j’ai des exemplaires perdus quelque part ("le bulletin des 
télécoms ?" Je ne suis pas certain du nom).
Il doit m'en rester aussi, c'était excellent.

Je n’ai pas réussi à trouver des archives en ligne. Ya pas des anciens dans la 
ML ?
Je vais fouiller chez moi, je suis certain d’avoir mis ça de côté.

Un numéro était consacré à la protection des bâtiments critiques à la foudre, 
en particulier les centraux téléphoniques. Ils décrivaient entre autre les 
moyens mis en oeuvre pour résister à des impacts
Comme l'évoque Philippe, un bâtiment hautement protégé, c'est déjà (mais
pas seulement) un bâtiment "empaqueté" par des "conducteurs de descente
étamés" (au moins aux angles vifs, c'est le minimum), c'est hors de prix
(section de 2x30 = 60 mm², au prix du cuivre...) mais efficace.
Irréalisable en standard. Moins cher, on trouve des câblettes étamées à
faire courir sur de petits supports le long des pignons, gouttières,
faîtages, plus ds pointes d'amorçage réparties sur ces chemins. Typique
en Allemagne et en zone continentale ou les orages d'été sont
particulièrement cossus.

En fait, c’est bien connu, parce que certaines industries sont bien protégées : 
installations Ex (raffineries, gaz, etc…) par exemple.

Les fabricants (Legrand, Schneider, Hager) ont des mini-guides pratiques (entre 
le grand public et le professionnel) sur leurs sites, faut pas hésiter à jeter 
un oeil.

Il y en a un qui va assez loin dans la théorie en parlant aussi des volumes 
protégés, etc… c’est Dehn (www.dehn.fr et 
https://www.dehn.fr/fr/catalogues).
Bon ils vendent non seulement tout ce qu’il faut, mais aussi leur service. Pour 
le coup, ils vont plus loin que les généralistes que j’ai mentionnés.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Foudre

[Philippe ASTIER via frnog]

Hello à tous,

Dans les années 80-90, le CCETT à Lannion avait un bulletin technique assez 
intéressant, dont j’ai des exemplaires perdus quelque part ("le bulletin des 
télécoms ?" Je ne suis pas certain du nom).

Un numéro était consacré à la protection des bâtiments critiques à la foudre, 
en particulier les centraux téléphoniques. Ils décrivaient entre autre les 
moyens mis en oeuvre pour résister à des impacts directs, et si je me souviens 
bien ils appelaient ça des bâtiments de « classe 4.

Quelqu’un saurait retrouver ça ? Je n’ai pas réussi encore. S’il y avait des 
archives ça serait juste génial.

On y retrouvait tout ce qui a déjà été dit : ceinture de terre autour du 
bâtiment, équipotentialité des baies, protection des pénétrations, etc etc. Bon 
les parafoudres de l’époque c’était plutôt exclusivement des éclateurs à gaz, 
on fait plus fin depuis, mais tout était là, et très bien étudié.

> Le 27 août 2023 à 13:09, Toussaint OTTAVI  a écrit :
> 
> Le 27/08/2023 à 07:39, Raphaël Jacquot a écrit :
>> Raphaël
>> qui est confronté régulièrement à la foudre dans les montagnes, mais qui a 
>> rarement perdu du matériel...
> 
> Les liaisons cuivre souterraines entre bâtiments, ce sont effectivement des 
> points d'entrée de choix pour les ondes de courant en cas d'impact de foudre 
> à proximité. Et ce, plus particulièrement en courant faible, car les circuits 
> électroniques ne sont pas prévus pour encaisser de tels chocs d'une part, et 
> pas grand monde ne pense à les protéger correctement d'autre part :-)
> 
> Alors, certes, cela ne répond pas au message initial, qui concerne plus 
> l'aspect diagnostic / curatif. Mais en préventif, pour la prochaine fois, 
> voici un certain nombre de bonnes pratiques à mettre en oeuvre :
> - Beaucoup de gens pensent à protéger les arrivées EDF, mais ne pensent pas 
> toujours aux courants faibles : réseau inter-bâtiments, alarmes, caméras, 
> ADSL... Il faut protéger *toutes* les entrées filaires d'un bâtiment, sans 
> exception. Et ce d'autant plus que le bâtiment est isolé / éloigné de tout 
> autre bloc de constructions.
> - Pour les liaisons inter-bâtiments, déjà, éviter le cuivre ! Même sur des 
> courtes distances de 20m-50m, mettre de la fibre. C'est un isolant naturel :-)
> - Souvent, les installateurs d'alarme ou vidéosurveillance ont tendance à 
> faire leurs propres installations et leurs propres câblages sans forcément 
> tenir compte de l'existant ni des recommandations. Aujourd'hui, tout 
> fonctionne en IP. Donc, s'il n'est pas possible de modifier leur câblage, les 
> laisser mettre leur équipement dans un coin à part, si possible en limite de 
> bâtiment, et isoler leur interface Ethernet du reste du  réseau par une 
> longueur de fibre.
> - S'il n'est vraiment pas possible de mettre un bout de fibre, et que le 
> cuivre reste obligatoire, maximiser les protections : parasurtenseur courant 
> faible adapté (il en existe pour Ethernet, xDSL et tous types de liaisons 
> filaires série). Eventuellement, mettre un petit switch premier prix en 
> "tampon" avant le switch qui coûte un bras et un rein.
> - Et, bien entendu, respecter les règles de base en matière de protection 
> contre les surtensions : installation de terre fiable, cables de terre les 
> plus gros et les plus courts possibles, connecter tous les chassis 
> métalliques à la terre (la baie, les bandeaux RJ) et entre eux par des 
> liaisons équipotentielles. Idéalement, à faite surtout sur les équipements de 
> périmètre les plus exposés, connecter les coffrets de chacun des équipements 
> (switches, routeurs, modems...) à la terre : derrière les boîtiers, il y a en 
> général une petite vis avec un sigle de terre; c'est à cela que çà sert :-)
> - Sur les installations professionnelles en points hauts, tous les bâtiments 
> sont cerclés avec des feuillards de mise à la terre de forte section, afin de 
> constituer une sorte de "cage de Faraday" (même si ce n'est pas l'étanchéité 
> aux ondes électromagnétiques qui est recherchée ici). Toutes les pénétrations 
> de bâtiments sont également protégées (les blindages des câbles sont mis à la 
> terre). Cà permet de constituer une grosse "boite métallique équipotentielle" 
> à travers laquelle l'onde de choc peut passer, mais pas entrer.
> 
> Enfin, quelques remarques plus théoriques :
> 
> L'idée, c'est qu'en cas d'impact de foudre a proximité, une onde de courant 
> de très forte intensité est générée en un temps très bref. Elle cherche à 
> s'évacuer, depuis le point d'impact vers le reste de la terre. Si, sur son 
> chemin, elle rencontre un câble électrique, le cuivre étant un conducteur de 
> choix bien meilleur que le sol terrestre, elle va l'emprunter en priorité, et 
> se propager à travers lui. Elle va ainsi arriver sur l'équipement de 
> terminaison (modem, port de switch, centrale d'alarme, ...). Là, plusieurs 
> choses peuvent se passer :
> - S'il y a un parasurtenseur : celui-ci va "évacuer" tout ou partie de l'onde 
> vers 

[FRnOG] [Alert] Coupure généralisée nord-est (Free + Jaguar)

[Philippe ASTIER via frnog]

Hello à tous,

Dans le nord-est de l’Alsace au moins, de 18h jusque vers 19h10, on vient de 
faire face à une grosse coupure fibre sur Free, Jaguar (Free Pro), ainsi que 
sur les données mobiles de ces deux opérateurs. La téléphonie est restée up 
tout le temps.

A priori, c’est revenu, mais des pans de routes sont encore HS, en IPv4 
principalement.
Par exemple, Apple et Google sont joignables en IPv6 uniquement, alors que 
Cloudflare est dispo aussi bien en IPv4 que v6.

Je suis le seul à voir ce genre de fantaisies ?

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[MISC] Re: [MISC] Re: [FRnOG] [MISC] [Émeutes] Interdiction des réseaux sociaux ?

[Philippe ASTIER via frnog]

Alors les deux « exemples » que tu donnes… je ne vois pas le rapport avec le 
sujet de la discussion.

En plus ce texte est archi dépassé quand on utilise des messagerie chiffrées de 
bout en bout.
Plus intéressant dans l’article que tu cites, justement, il y a de la 
réglementation sur la manière de procéder à des interceptions...


Le 2 juil. 2023 à 20:23, Richard Klein  a écrit :

Deux exemple pour remettre de l’huile sur le deux en mode complotiste et 
platiste:
Covide 19
Et
<https://www.nextinpact.com/article/23468/101102-interceptions-legales-correspondances-mobiles-pourront-etre-dupliquees-a-distance>
[147.jpeg]
Interceptions légales : les correspondances mobiles pourront être dupliquées à 
distance<https://www.nextinpact.com/article/23468/101102-interceptions-legales-correspondances-mobiles-pourront-etre-dupliquees-a-distance>
nextinpact.com<https://www.nextinpact.com/article/23468/101102-interceptions-legales-correspondances-mobiles-pourront-etre-dupliquees-a-distance>
Philippe va faire un tours sur le site de la quadrature du net pour leurs 
demander si ils sont complotistes ? :-)

Richard

Envoyé de mon iPhone

Le 2 juil. 2023 à 19:57, Philippe ASTIER via frnog  a écrit :

Un peu de bon sens bon sang, c’est des conneries.

Qu’ils étudient, surveillent et réfléchissent à l’impact des réseaux sociaux, 
c’est normal, ne serait-ce qu’en terme de veille (suivre où pourraient aller 
les émeutiers) et de veille techno.

Des restrictions qui iraient plus loin, il faudrait un cadre légal et 
probablement la décision d’un juge au moins, et ça mettrait le feu aux poudres, 
ce qui serait encore plus une connerie politique.

Au passage, ni Apple, ni Google ne sont en mesure de fournir les coordonnées 
GPS d’un téléphone, ça aussi c’est vraiment de la fake news à deux balles.

Faut arrêter le complotisme à tout va, on n’est pas dans une république 
bananière ou une dictature. Alors, ok, tout ce qui est aux limites du légal 
sera probablement testé, mais ça n’ira pas plus loin.

Par contre, vous avez réfléchi à l’impact de bandes de crétins qui 
attaqueraient un DC ?


Sincèrement, le niveau technique de la liste est en baisse, et la politique n’a 
pas lieu d’être.


Le 2 juil. 2023 à 19:14, Stephane Bortzmeyer  a écrit :

On Sun, Jul 02, 2023 at 07:06:39PM +0200,
Pierre Col  wrote
a message of 205 lines which said:

Attention aux fake news en ce moment :

Je sais et j'ai déjà répondu à cet argument :

Attention, il s'agirait d'un faux communiqué attribué à la DG de la
Police Nationale abondement relayé (comme d'hab quoi !).

Pas d'accord, ce sont deux choses bien différentes. L'article de
là-bas qui dit que la Police s'est renseignée (ce qui n'a PAS été
démenti). Et le faux communiqué (qui prétendait qu'une décision avait
été prise).


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[MISC] Re: [FRnOG] [MISC] [Émeutes] Interdiction des réseaux sociaux ?

[Philippe ASTIER via frnog]

Un peu de bon sens bon sang, c’est des conneries.

Qu’ils étudient, surveillent et réfléchissent à l’impact des réseaux sociaux, 
c’est normal, ne serait-ce qu’en terme de veille (suivre où pourraient aller 
les émeutiers) et de veille techno.

Des restrictions qui iraient plus loin, il faudrait un cadre légal et 
probablement la décision d’un juge au moins, et ça mettrait le feu aux poudres, 
ce qui serait encore plus une connerie politique.

Au passage, ni Apple, ni Google ne sont en mesure de fournir les coordonnées 
GPS d’un téléphone, ça aussi c’est vraiment de la fake news à deux balles.

Faut arrêter le complotisme à tout va, on n’est pas dans une république 
bananière ou une dictature. Alors, ok, tout ce qui est aux limites du légal 
sera probablement testé, mais ça n’ira pas plus loin.

Par contre, vous avez réfléchi à l’impact de bandes de crétins qui 
attaqueraient un DC ?


Sincèrement, le niveau technique de la liste est en baisse, et la politique n’a 
pas lieu d’être.


Le 2 juil. 2023 à 19:14, Stephane Bortzmeyer  a écrit :

On Sun, Jul 02, 2023 at 07:06:39PM +0200,
Pierre Col  wrote
a message of 205 lines which said:

Attention aux fake news en ce moment :

Je sais et j'ai déjà répondu à cet argument :

Attention, il s'agirait d'un faux communiqué attribué à la DG de la
Police Nationale abondement relayé (comme d'hab quoi !).

Pas d'accord, ce sont deux choses bien différentes. L'article de
là-bas qui dit que la Police s'est renseignée (ce qui n'a PAS été
démenti). Et le faux communiqué (qui prétendait qu'une décision avait
été prise).


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Blocage Uptobox chez Orange (DNS)

[Philippe ASTIER via frnog]

Dura lex, sed lex.

Oui c’est compliqué, mais c’est la loi. 
D’autres font mal ? Possible, mais ça n’a jamais été une excuse valable. 
Ils se feront peut-être prendre, ou pas… C’est la vie.

Ce n’est pas parce qu’internet permet de déporter les sites dans des pays avec 
des législations différents que ça autorise de se dédouaner des contraintes 
légales d’un pays.

Fondamentalement, des fichiers illégaux ont été repérés, les ayants droit ont 
demandé au tribunal d’agir, celui-ci a ordonné aux FAIs (basés en France sur 
lesquels ils peut légalement agit) d’en rendre l’accès plus difficile à titre 
conservatoire. Ça ne me choque pas.

Et si Uptobox supprime ce contenu illégal, ça ne me choquerait pas qu’on lève 
le filtrage DNS.

Eh oui, sur le territoire européen, la RGPD s’applique, et la CJUE a le droit 
de prendre des décisions.

> Le 2 juin 2023 à 18:54, Gwenaël Oberlinger  a 
> écrit :
> 
> Tout à fait, tu as parfaitement raison c'est pour cela qu'il y a une très
> bonne collaboration avec les autorités françaises (je pense au terrorisme
> par exemple), même les ayants droits (LCEN), ou les associations (violences
> animales, pédopornographique).  On maintient même une liste de contacts
> 'urgent' avec les autorités FR en cas de signalement urgent.
> 
> A noter que les utilisateurs Français représentent en gros 20% du marché.
> C'est déjà pas mal mais c'est pas genre 50 ou 75%.  Respecter toutes les
> lois de tous les pays pour une petite boite n'est pas toujours évident et
> je dirais même pour tout site à vocation internationale (nombreux sont les
> sites web de services ouverts à l'international).
> 
> 
> 
> Il y a sans doute des points à améliorer comme partout (par ex: avec
> SCHREMS II je n'imagine pas le nombre de boites FR ayant un site non
> conforme...), très clairement.  Mais encore une fois, ce n'est pas ça qui
> est reproché, j'explique juste à titre informatif.
> 
> 
> 
> 
> On Fri, 2 Jun 2023 at 20:41, Romain  wrote:
> 
>> Peu importe ton pays si tu veux cibler des utilisateurs français il faut
>> respecter les normes françaises non ?
>> 
>> Je dis ça sans trop savoir mais je crois que c’est comme ça. Après si les
>> UAE ne fournissent pas les éléments que la France exige niveau noms /
>> numéros c’est différent.
>> 
>> Le ven. 2 juin 2023 à 18:35, Gwenaël Oberlinger <
>> gwenael.oberlin...@gmail.com> a écrit :
>> 
>>> en quoi cela te choque? Une société non européenne n'a pas de SIRET, les
>>> UAE n'ont pas de service postal (pas de boîtes aux lettres) mais une
>>> adresse de siège (qui est clairement indiquée).
>>> 
>>> Les sociétés sont renouvelées et validées tous les ans, un officiel passe
>>> voir les bureaux etc..  Je pourrais en parler pendant des heures, ici tout
>>> est différent, le contrôle technique des voitures c'est tous les ans et les
>>> permis sont renouvelés avec tests de vue tous les 2 ans.  Je fais du hors
>>> sujet parce que tu as l'air vraiment fermé d'esprit :/.
>>> 
>>> Après, tu ne peux pas connaître tous les pays du monde, donc je
>>> t'apprends sûrement certaines choses. Mais encore une fois, il ne faut pas
>>> parler trop vite.
>>> 
>>> J'ai personnellement un contrat de travail UAE, avec des fiches de
>>> salaires et je pense que ça te choquerait de savoir qu'elles sont rédigées
>>> en arabe? 
>>> 
>>> Tout pareil, les CGU Uptobox interdisent la pornographie. Pourquoi cela?
>>> c'est parfaitement autorisé en Europe :) !   Et bien, c'est interdit ici et
>>> nous respectons parfaitement cela.
>>> 
>>> Voilà voilà.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Fri, 2 Jun 2023 at 20:12,  wrote:
>>> 
 les CGU, sans siret, sans patronyme du responsable légal, sans adresse
 postale, clairement précisées.. j'espère qu'il n'y a pas que moi que ca
 choque, en tout cas pour un site commercial..
 
 avec un siège social à dubai...
 
 
 De : Gwenaël Oberlinger 
 À : Romain 
 Sujet : Re: [FRnOG] [TECH] Blocage Uptobox chez Orange (DNS)
 Date : 02/06/2023 17:15:46 Europe/Paris
 Copie à : l...@netc.fr;
   Raphaël Jacquot ;
   frnog@frnog.org
 
 Il y a des CGU et une courte page "à propos", c'est un choix volontaire
 qu'elles soient très courtes tout en restant à mon sens assez précises
 pour
 les utilisateurs. Il est souvent très facile de renvoyer un utilisateur
 contactant le support vers les CGU sans avoir à lui sortir un
 texte imbitable.
 
 Si l'idée était de dire qu'Uptobox est impossible à contacter, c'est
 faux,
 l'adresse abuse existe, un support client (open à tous) également.
 
 De toute façon cette notion de mentions légales n'est pas du tout ce qui
 est reproché ici. A titre informatif, les "attaquants" n'ont en aucun cas
 reproché ça, et tant mieux.
 
 
 
 
 On Fri, 2 Jun 2023 at 18:58, Romain  wrote:
 
> Ça me gêne aussi, mais pour rappel (surtout la deuxième partie).
> 
> Tout simplement parce que dans une 

Re: [FRnOG] [TECH] Blocage Uptobox chez Orange (DNS)

[Philippe ASTIER via frnog]

En l’espèce, on s’en fout de ce qui se passe en UAE.

Le site a hébergé des fichiers illégaux au sens de la loi française, le 
tribunal a appliqué les sanctions qu’il jugeait nécessaires.
Et comme on est un état de droit, on a le droit de faire appel voire d’aller en 
cassation.

Sur le territoire français, les lois Européennes et Françaises sont en vigueur.
Les sites accessibles aux internautes basés sur nos territoires doivent les 
respecter.

Sinon, je suis certain qu’on peut trouver des pays où la vente d’armes, 
d’explosifs ou autre choses illégales ne sont pas interdites.
Donc pas de souci, on laisse faire ?

Je sais que les soucis de territorialité ne sont pas simples, et qu’on peut se 
déporter avec des VPN, etc… mais ce n’est pas le débat.
Ce n’est pas parce qu’internet complique les choses que la loi ne s’applique 
pas.

C’est surprenant d’accepter de respecter les lois de l’UAE, mais pas celles du 
pays cible si je comprends bien ? C’est chaud comme allégation...

Le moyen technique qui a été mis en place, c’est de filtrer le DNS, on sait 
tous que c’est pas génial, que ça se contourne, etc, mais on se bat comme on 
peut et je suspecte qu’il n’y a pas de convention avec les UAE.

Bref oui… Ca ressemble à du megaupload, quoi qu’on en dise.

Le 2 juin 2023 à 18:35, Gwenaël Oberlinger  a 
écrit :

en quoi cela te choque? Une société non européenne n'a pas de SIRET, les
UAE n'ont pas de service postal (pas de boîtes aux lettres) mais une
adresse de siège (qui est clairement indiquée).

Les sociétés sont renouvelées et validées tous les ans, un officiel passe
voir les bureaux etc..  Je pourrais en parler pendant des heures, ici tout
est différent, le contrôle technique des voitures c'est tous les ans et les
permis sont renouvelés avec tests de vue tous les 2 ans.  Je fais du hors
sujet parce que tu as l'air vraiment fermé d'esprit :/.

Après, tu ne peux pas connaître tous les pays du monde, donc je t'apprends
sûrement certaines choses. Mais encore une fois, il ne faut pas parler trop
vite.

J'ai personnellement un contrat de travail UAE, avec des fiches de salaires
et je pense que ça te choquerait de savoir qu'elles sont rédigées en
arabe? 

Tout pareil, les CGU Uptobox interdisent la pornographie. Pourquoi cela?
c'est parfaitement autorisé en Europe :) !   Et bien, c'est interdit ici et
nous respectons parfaitement cela.

Voilà voilà.







On Fri, 2 Jun 2023 at 20:12, mailto:l...@netc.fr>> wrote:

les CGU, sans siret, sans patronyme du responsable légal, sans adresse
postale, clairement précisées.. j'espère qu'il n'y a pas que moi que ca
choque, en tout cas pour un site commercial..

avec un siège social à dubai...


De : Gwenaël Oberlinger 
À : Romain 
Sujet : Re: [FRnOG] [TECH] Blocage Uptobox chez Orange (DNS)
Date : 02/06/2023 17:15:46 Europe/Paris
Copie à : l...@netc.fr;
  Raphaël Jacquot ;
  frnog@frnog.org

Il y a des CGU et une courte page "à propos", c'est un choix volontaire
qu'elles soient très courtes tout en restant à mon sens assez précises pour
les utilisateurs. Il est souvent très facile de renvoyer un utilisateur
contactant le support vers les CGU sans avoir à lui sortir un
texte imbitable.

Si l'idée était de dire qu'Uptobox est impossible à contacter, c'est faux,
l'adresse abuse existe, un support client (open à tous) également.

De toute façon cette notion de mentions légales n'est pas du tout ce qui
est reproché ici. A titre informatif, les "attaquants" n'ont en aucun cas
reproché ça, et tant mieux.




On Fri, 2 Jun 2023 at 18:58, Romain  wrote:

Ça me gêne aussi, mais pour rappel (surtout la deuxième partie).

Tout simplement parce que dans une telle procédure, prévue par la loi
régulièrement votée par le législateur (article L.336-2 du code de la
propriété intellectuelle) il n'y a aucune obligation de mettre dans la
cause l'intermédiaire technique visé.

A plus forte raison quand ce dernier ne dispose pas de mentions légales
conformes à la loi.


Le ven. 2 juin 2023 à 16:46, Gwenaël Oberlinger <
gwenael.oberlin...@gmail.com> a écrit :

Si tu trouve ça normal qu'un site internet (qui a une vraie société et
structure légale derrière) soit bloqué *sans être partie *du jugement,
je
pense que tu as de graves problèmes :/.

Si il y avait un vrai procès avec analyse complètes de preuves et j'en
passe ça serait sans soucis c'est la justice c'est normal. Mais ici,
c'est
n'importe quoi.

C'est tellement incroyable que y'a 30ans (oui oui) pour faire opposition
au
jugement car le site visé n'est pas partie au jugement et n'a jamais été
notifié de quoi que ce soit.


On Fri, 2 Jun 2023 at 18:32,  wrote:

je vois pas le rapport...


De : Gwenaël Oberlinger 
À : l...@netc.fr
Sujet : Re: [FRnOG] [TECH] Blocage Uptobox chez Orange (DNS)
Date : 02/06/2023 14:24:24 Europe/Paris
Copie à : Raphaël Jacquot ;
frnog@frnog.org

Effectivement Megaupload payait les gens :). Pas Uptobox.


Avant de parler peut être vérifier? :)

On Fri 2 Jun 2023 at 15:30,  wrote:

bonjour

j'ai l'impression de 

Re: [FRnOG] [MISC] L'avenir des DC ?

[Philippe ASTIER via frnog]

Oui. Par le charbon et c’est une catastrophe.


Le 15 avr. 2023 à 10:44, Hugues Voiturier  a écrit :

Oui : avec un usage massif de centrales a gaz (soi disant h2 ready, mais pour 
l’instant c’est bien du méthane) et de charbon (jusqu’a une date qui n’engage 
que ceux qui y croient) :)


Hugues Voiturier
Consultant en architecture réseau
AS2027

On 15 Apr 2023, at 10:41, David Ponzone  wrote:

Ok mais l’article (d’un intérêt douteux) n’explique pas comment les allemands 
ont réglé le problème de l’intermittence du solaire et de l’éolien.

Quelqu’un sait ?

David Ponzone



Le 15 avr. 2023 à 10:06, Luc Novales  a écrit :

Ouf !

Merci Stéphane pour ces rappels à la réalité, ce troll du vendredi partait 
vraiment en vrille ;)

Les Allemands sortent définitivement du nucléaire aujourd'hui et cela ne les 
empêchera pas de sortir du charbon en 2038.

https://www.francetvinfo.fr/replay-radio/le-monde-est-a-nous/l-allemagne-acte-la-fin-du-nucleaire-civil-en-debranchant-ses-trois-derniers-reacteurs_5740958.html


Bon WE.

Luc.


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[ALERT] Re: [FRnOG] [ALERT] Chez Volkswagen, l'option de conduite autonome pourrait se payer à chaque déplacement

[Philippe ASTIER via frnog]

Ca suffit, le spam Clubic, c’est vraiment pas le but de la liste, et pas avec 
un tag ALERT.

DEHORS ASAP.

Le 18 juil. 2022 à 15:45, Thomas via frnog 
mailto:frnog@frnog.org>> a écrit :

https://www.clubic.com/volkswagen/actualite-430302-chez-volkswagen-l-option-de-conduite-autonome-pourrait-se-payer-a-chaque-deplacement.html
---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Nombreuses coupures de fibres optiques en France

[Philippe ASTIER via frnog]

Ouais, alors pas tout à fait hein, il y a un codage, c’est pas aussi direct. Je 
suis pas certain que l’on puisse mesurer la différence de consommation entre un 
zéro et un un.

Mais en revanche, avoir un trajet plus long, ça consommera toujours plus, 
simplement parce qu’on va franchir des équipements en plus : répéteurs/amplis, 
routeurs, switchs, que sais-je. C’est des millisecondes de perdues et de 
l’énergie en plus de manière certaine, et c’est pas si négligeable que ça.

Faire tout transiter par une ou quelques plaques centralisées, ça facilite 
sûrement la gestion, ça coûte probablement moins cher, mais c’est à peu près 
certainement plus cher en coût énergétique, et surtout bien peu résilient… la 
preuve en a été faite cette semaine.

Ce que je trouve dommage, c’est qu’en cas de crise, on n’a même pas été capable 
de basculer temporairement sur des liens de peering plus régionaux. Je me doute 
bien qu’on va pas non plus faire ça dans tous les NRO/NRA, on est d’accord.

J’espère vraiment qu’il va y avoir une réflexion de fond la dessus, parce que 
la vulnérabilité a été exploitée.


> Le 29 avr. 2022 à 12:48, Richard Klein  a écrit :
> 
>> Par contre je ne vois pas en quoi un paquet consommerait plus ou moins.
> 
> Un octet a 255 donc les 8 bits a 1 va allumer l'optique donc consommation .
> Ok 8 bits a 1 c'est rien pour la consommation mais c'est les gouttes de
> pluie qui font les ruisseaux et rivières !
> 
> Richard
> 
> Le ven. 29 avr. 2022 à 11:28, Léo El Amri via frnog  a
> écrit :
> 
>> 
>> On 29/04/2022 09:16, Toussaint OTTAVI wrote:
>>> Le 29/04/2022 à 08:27, David Ponzone a écrit :
>>> 
 (et niveau empreinte CO2 non plus probablement).
>>> 
>>> Là, par contre, je ne vois pas comment un paquet qui fait
>>> Ajaccio-Ajaccio pourrait consommer plus de CO2 que le même paquet qui
>>> monte à Paris, fait un petit tour sur le périph' optique, puis
>>> redescend. J'ai même eu des cas où çà passait... par la Nouvelle-Zélande
>>> !
>> 
>> On est vendredi, mais je prend ça au premier degrés quand même, car
>> c'est un sujet très intéressant. Est-ce qu'il y a eu des études sur
>> l'impact écologique des télécommunications terrestres (cuivre ou fibre) ?
>> 
>> D'un point de vue purement écologique :
>> 
>> Je vois la centralisation comme un point positif, pour la mutualisation
>> des ressources et la possibilité de ne pas trop surdimensionner les
>> capacités (quand tout passe par un point, c'est plus facile de
>> dimensionner pour 100% de capacité plutôt que quand tu n'es pas sûr de
>> par quel chemin vont passer tes paquets).
>> 
>> Par contre je ne vois pas en quoi un paquet consommerait plus ou moins
>> en fonction de la distance. Traverser 200km ou 1km, ça devrait
>> revenir au même, théoriquement. Physiquement et techniquement on a
>> forcément des noeuds sur notre chemin, et chaque noeud consomme un peu,
>> que ce soit un simple répéteur de signal ou un routeur. Dites moi si je
>> me trompe. Si je ne me trompe pas, alors on peut réduire le problème à :
>> "une route avec plus de noeuds consommera plus qu'une route avec moins
>> de noeuds, quelle que soit sa distance physique".
>> 
>> Et dans ce cas, je me pose une question à laquelle je n'ai pas de
>> réponse : à quoi ressemblerait un maillage plus fin ?
>> 
>> Je n'ai certes pas de réponse à cette question, mais je me dis quand
>> même que pour passer à un maillage plus fin, il suffit d'interconnecter
>> d'avantage les noeuds, sans avoir nécessairement besoin d'en ajouter.
>> Est-ce naïf ?
>> 
>> Et, pour "l'efficience", est-ce qu'on ne pourrait pas conserver des
>> longues lignes de cuivre/fibre qui permettent de "court-circuiter" une
>> série de plus petites routes ? (à la façon dont fonctionne le réseau
>> routier ? Pour faire un Paris -> Lyon, si on veut être efficace, on ne
>> passe pas par des départementales)
>> 
>> Enfin, mais ça c'est tellement une évidence que je ne devrais même pas
>> le dire. Avoir plus de matériel est moins "écologique" qu'avoir moins de
>> matériel (impact écologique de la fabrication, toussa toussa). Et poser
>> un câble, qu'il soit en cuivre ou en fibre, est coûteux en énergie, et
>> demande de traverser des écosystèmes, c'est à prendre en compte dans le
>> calcul de l'impact écologique.
>> 
>> --
>> - Léo
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Nombreuses coupures de fibres optiques en France

[Philippe ASTIER via frnog]

Bah oui, ya des trucs qui ne vont pas…
Idem pour moi hier, sur Free, impossible de sortir de mon premier hop, alors 
que si je ne me trompe pas il y a du peering sur Strasbourg.

Et quand je passe de Free à OVH, il y a au moins 12 hops, ça passe par Paris, 
et j’ai une latence de 15 ms pour faire… 2 km physiques. C’est absurde, ca 
laisse songeur.

Je ne vise pas Free, j’ai un deuxième lien OBS, c’est pareil, ça passe par 
Paris, sauf que c’était pas coupé hier...


Après, je peux comprendre qu’il y a ait des intérêts financiers en jeu à faire 
passer du peering par différents endroits, que les opérateurs préfèrent 
utiliser leur backbone en propre, je ne suis pas un spécialiste de la chose. Là 
où ça devient choquant, c’est que même en cas de panne, on n’a pas plus de 
redondance.

Internet n’a pas été fait pour ça, bien au contraire. En cas d’action 
coordonnée plus aggressive, on a maintenant tous compris qu’avec 10-15 points 
de coupure ciblés, on déconnecte la France. C’est gravissime en fait.


> Le 28 avr. 2022 à 12:04, Erwan David  a écrit :
> 
> Le 28/04/2022 à 11:34, SD76 a écrit :
>> N'y a t-il pas des pistes à creuser du côté de la SNCF pour améliorer
>> le maillage ?
> 
> Peut-être aussi de la manière dont sont organisés les points d'échange. Entre 
> chez moi (Free) et le bureau ça passe par Orange (peering à Nantes) mais le 
> trafic remonte à Paris (Montsouris...) avant de passer chez Free.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Nombreuses coupures de fibres optiques en France (Was: Coupure wave zayo)

[Philippe ASTIER via frnog]

Au risque de fâcher, il va aussi falloir réfléchir à la structure apparemment 
trop en étoile du réseau.

Même si je comprends très bien que trois grosses coupures en RP ait un gros 
impact, j’ai du mal à comprendre pourquoi les provinciaux sont autant affectés.
C’est pas comme ça qu’on fait un Internet solide.

Il y a des peerings en province, des liens vers l’étranger, et pourtant on 
n’avait plus aucun trafic ? 
Que ça impacte la capacité, la latence, que ça fasse domino (ou boule de neige 
selon votre sensibilité), ok… mais de là à avoir un tel impact, ça me laisse 
vraiment perplexe.


> Le 27 avr. 2022 à 14:27, Toti FRnOG  a écrit :
> 
> C'est quand même dur que 2 artères soient coupées chez 2 fournisseurs
> différents ...
> 
> J'ai eu un retour de Zayo, le technicien arrive à 14h30 sur site, on croise
> les doigts, mais j'ai peur qu'il y est beaucoup de dégat.
> 
> Le mer. 27 avr. 2022 à 13:45, Francis DHUMES  a
> écrit :
> 
>> Bonjour,
>> 
>> Informations complémentaire reçues d'Alphalink (hors ticket d'IG), c'est
>> donc à considérer point de vue des services et produits qu'ils utilisent.
>> 
>> L’incident en cours impacte Paris-Lyon, Paris-Strasbourg et Paris Lille.
>> L’incident n’est pas sur notre réseau propre et impactent fortement nos
>> confrères également.
>> Nous avons bien deux fournisseurs pour chaque remonté vers Paris mais une
>> plaque importante qui impacte l’ensemble des fournisseurs est coupée.
>> Les équipes techniques du fournisseur sur place  et ils ont localisé le
>> défaut .
>> Malheureusement nous n’avons pas d’autres information, nous escaladons
>> sans arrêt les trois fournisseurs que nous avons . Dès que nous avons des
>> informations plus précises nous reviendront vers vous.
>> On maintient une forte pression sur les fournisseurs tant que nous n’avons
>> pas la résolution du problème.
>> Zayo vient de nous informer qu’il y a plusieurs cables SFR sectionnés et
>> que SFR est sur place en train de réparer.
>> 
>> Francis Dhumes
>> Responsable de la sécurité des systèmes d’information (RSSI) / Chief
>> Information Security Officer (CISO)
>> Responsable  télécommunications
>> +33 4 73 980 980 / +33 6 12 06 56 12
>> f.dhu...@cegialfa.fr
>> 
>> 
>> -Message d'origine-
>> De : frnog-requ...@frnog.org  De la part de
>> Stephane Bortzmeyer
>> Envoyé : mercredi 27 avril 2022 12:24
>> À : frnog.kap...@antichef.net
>> Cc : frnog-al...@frnog.org
>> Objet : [FRnOG] Re: [ALERT] Nombreuses coupures de fibres optiques en
>> France (Was: Coupure wave zayo)
>> 
>> On Wed, Apr 27, 2022 at 11:25:27AM +0200,
>> Stephane Bortzmeyer  wrote
>> a message of 14 lines which said:
>> 
>>> Et sur Numérama :
>>> 
>>> 
>> https://www.numerama.com/tech/939175-detranges-coupures-de-fibre-optique-en-france-la-coincidence-interroge.html
>> 
>> Une mystérieuse source étatique anonyme confie à l'Obs qu'il s'agit de
>> malveillance :
>> 
>> 
>> https://www.nouvelobs.com/faits-divers/20220427.OBS57722/plusieurs-cables-sectionnes-a-l-origine-d-une-importante-panne-internet-en-france.html
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Coupure wave zayo

[Philippe ASTIER via frnog]

Sur mon monitoring, j’ai les premières alertes à 3h12 ce matin, avec les 
tunnels VPN qui tombent en quasi simultané.

(BTW ça correspond à pas mal de coupures chez Free qu’on peut voir sur 
Free-réseau : https://www.free-reseau.fr)


Le 27 avr. 2022 à 09:09, Toti FRnOG mailto:tot...@gmail.com>> 
a écrit :

Merci, oui j'ai eu ce retour.
mais il y a aussi :
- les liens covage
- les EFM en local (lyon)
- collecte SIEA

Il n'y a pas de boucle nationale ? ...

Le mer. 27 avr. 2022 à 08:51, Oliver varenne 
mailto:o.vare...@ipconnect.fr>> a
écrit :

Coupure sur fibre a priori
En tout cas c'est ce que remonte alphalink


Nous subissons depuis 4H cette nuit un incident sur plusieurs
interconnexions reliant certain PoPs et nos Datacenters à Courbevoie.
Cette incident provoquent l'isolement de trois de nos PoP Vénissieux, Metz
et Strasbourg.
Nous avons alerté nos fournisseurs qui nous confirment une coupure Fibre
et leurs actions en cours sur le terrain.
Les collectes EFM de ces régions ont été remontées sur Courbevoie afin de
rétablir les liaisons.
Néanmoins cet incident provoque actuellement une rupture de continuité sur
les liaisons Executive Accès/S-FTTH, EFM(Celan) et Interconnexion collectés
sur ces PoPs.


Cordialement,



Olivier Varenne
Président, R et développement
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous !



-Message d'origine-
De : frnog-requ...@frnog.org 
mailto:frnog-requ...@frnog.org>> De la part de
Toti
FRnOG
Envoyé : mercredi 27 avril 2022 08:50
À : frnog-alert mailto:frnog-al...@frnog.org>>
Objet : [FRnOG] [ALERT] Coupure wave zayo

Bonjour,
J'ai un incident sur ma wave Paris <-> Lyon depuis 03:41 Je suis chez
Zayo.
Est ce que je suis le seul ?
Est ce qu'il y a que Zayo ?

Merci.

---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Tiens, STARLINK is out.

[Philippe ASTIER via frnog]

Merci pour le lien.

Techniquement, Starlink sait où elle émet et peut couper les liens vers les 
clients français.

Que des associations écologistes utilisent un argument de non mise en 
concurrence pour leur quête, et venir des mois après la mise en prod, ça 
dérange.

Le 6 avr. 2022 à 08:53, Yoann THOMAS 
mailto:ythomas2...@gmail.com>> a écrit :

Pauvre France! Si encore il y avais des solutions alternatives pour connecter 
correctement les societes en zone blanche.

Bonne journee
Yoann Thomas
Directeur associe
Directeur technique
Envoyé de mon iPhone

Le 6 avr. 2022 à 08:31, Rémy Grünblatt 
mailto:r...@grunblatt.org>> a écrit :

Hello,

Sur le sujet, autant mettre le lien vers la décision elle même: 
http://www.conseil-etat.fr/fr/arianeweb/CE/decision/2022-04-05/455321

Rémy

On 05/04/2022 22:44, thomas via frnog wrote:
Hello


Si vous n’avez pas vu passer :


https://www.msn.com/fr-fr/actualite/france/internet-par-satellites-starlink-
perd-ses-autorisations-de-fr%C3%A9quence-en-france/ar-AAVT9bv?ocid=msedgdhp

=U531=ee1726c2709248ffa25dfc05582aaff0

ou

https://www.lefigaro.fr/flash-eco/starlink-perd-ses-autorisations-de-frequen
ce-en-france-20220405


Décidément nos campagnes lointaines mais néanmoins verdoyantes ne sont pas
aidées…


T



---
Liste de diffusion du FRnOG
http://www.frnog.org/

--
Rémy Grünblatt -- Maître de Conférences @ Télécom Sud-Paris
Mobile: 0651740613
Email Perso: r...@grunblatt.org
Email Pro: 
remy.grunbl...@telecom-sudparis.eu
Page Perso: https://remy.grunblatt.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Tiens, STARLINK is out.

[Philippe ASTIER via frnog]

Ben en fait c’est absurde.

Ça ne coupera pas le service, ça le rendra juste un peu plus lent parce que les 
paquets vont devoir être routés sans passer par les stations terrestres 
françaises, donc latence plus élevée, débit un peu impacté. Pour le moment, les 
liens intersatellites si je ne me trompe pas sont encore en test, donc il y 
aura peut-être aussi quelques trous de couverture.

Je suppose que juridiquement, utiliser son antenne sur une bande de fréquences 
qui n’est plus autorisée serait illégal, mais bonjour pour aller faire la 
chasse aux contrevenants…

Et pour les frontaliers ?

C’est du bien beau délire tout ça...

> Le 6 avr. 2022 à 07:56, Yoann QUERET  a écrit :
> 
> 
> On 06/04/2022 07:37, Mickael Monsieur wrote:
>> On sait si starlink a déjà cessé d’émettre ?
> 
> Salut,
> 
> J'ai un accès Starlink en Haute-Savoie qui fonctionne toujours, et je me 
> posais la question des conséquences de ce retrait des autorisations et des 
> échéances..
> 
> Ca me semble difficile de couper le service en France uniquement. Peut-être 
> en fonction du lieu d'installation ?
> 
> Yoann
> 
> Yoann QUERET
> yo...@queret.net
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Russie / Monde

[Philippe ASTIER via frnog]

Cela dit, Cogent a tout de même coupé tous ses liens avec la Russie, c’est pas 
rien.

https://www.kentik.com/blog/cogent-disconnects-from-russia/


Le 8 mars 2022 à 20:13, 
frnog.kap...@antichef.net a écrit :

Bonsoir,

on a vu repasser l'idée que la Russie allait se déconnecter du reste
d'internet le 11 mars. Il s'agissait d'une mauvaise interprétation de
documents officiels bien réels.

Ce dont il est question c'est pour les portails et site web gouvernementaux de
s'affranchir de leur dépendance à des services extérieurs.
Il s'agit de ne plus utiliser l'hébergement à l'étranger, et migrer vers des
services appartenant à la Russie, de retirer les scripts de société étrangère
comme google analytics ou le pistage de facebook,

La logique est celle de la résilient en anticipant sur la possibilité que ces
société cessent de leur fournir ces services et ainsi s'assurer que ces sites
resteront accessibles dans différents scénarios hostiles.

Andrey  Chernenko a bien précisé qu'ils ne planifient pas de se couper du reste
de l'Internet.

source: https://nitter.fdn.fr/shakirov2036/status/1500649169454878724

Par contre cogent a effectivement coupé la connection avec la Russie et fermé
ses services, il y a 3 ou 4 jours. c'était le 2eme plus gros FAI en Russie:
https://fossbytes.com/cogent-internet-backbone-disconnect-from-russia/



On vendredi 25 février 2022 16:56:17 CET Matic Vari - varima...@gmail.com
wrote:
Bonjour,

Sinon des effets sur les réseaux vers la Russie et vers l'Ukraine?

J'ai entendu parler de cyberattaques massive en Ukraine.

Cdlt,





---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] OVH mort ?

[Philippe ASTIER via frnog]

A priori, erreur humaine lors d’une intervention sur le DC US.
 
https://twitter.com/olesovhcom/status/1448196879020433409 



> Le 13 oct. 2021 à 09:32, Mickael MONSIEUR  a 
> écrit :
> 
> On a vérifié les pompiers de Roubaix ?
> 
> Le mer. 13 oct. 2021 à 09:28, Oliver varenne  a écrit 
> :
>> 
>> Tout ce qui est chez OVH semble mort !
>> Quelqu'un au courant de quoi que ce soit ?
>> 
>> 
>> 
>> Cordialement,
>> 
>> [cid:image001.png@01D7C014.42678B40]
>> 
>> Olivier Varenne
>> Co-gérant, Commercial & Développeur
>> T +33 (0)4 27 04 40 00 | ipconnect.fr
>> 
>> Suivez-nous !
>> [picto-twitter][picto-youtube][picto-linkedin]
>> [cid:image005.jpg@01D7C014.42678B40]
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] OVH mort ?

[Philippe ASTIER via frnog]

Exact, tout ce que j’ai comme service ou serveur chez OVH (SIP, web, dédié) est 
injoignable, comme le site d’OVH même.
Essayé depuis Free, Orange Pro et un troisième opérateur.

> Le 13 oct. 2021 à 09:25, Oliver varenne  a écrit :
> 
> Tout ce qui est chez OVH semble mort !
> Quelqu'un au courant de quoi que ce soit ?
> 
> 
> 
> Cordialement,
> 
> [cid:image001.png@01D7C014.42678B40]
> 
> Olivier Varenne
> Co-gérant, Commercial & Développeur
> T +33 (0)4 27 04 40 00 | ipconnect.fr
> 
> Suivez-nous !
> [picto-twitter][picto-youtube][picto-linkedin]
> [cid:image005.jpg@01D7C014.42678B40]
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Coupure Free -> 1.1.1.1

[Philippe ASTIER via frnog]

Ca a l’air reparti, mais juste avant le premier traceront a galéré, cf 
ci-dessous.

traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets
 1  192.168.0.2 (192.168.0.2)  0.489 ms  0.155 ms  0.170 ms
 2  192.168.17.254 (192.168.17.254)  0.402 ms  0.444 ms  0.368 ms
 3  194.149.169.93 (194.149.169.93)  8.130 ms  8.555 ms  11.011 ms
 4  * * *
 5  * * *
 6  be2102.ccr41.par01.atlas.cogentco.com (154.54.61.17)  10.622 ms  9.022 ms  
8.651 ms
 7  be2318.ccr32.bio02.atlas.cogentco.com (154.54.61.117)  21.316 ms  21.652 ms
be2315.ccr31.bio02.atlas.cogentco.com (154.54.61.113)  21.214 ms
 8  be2332.ccr42.dca01.atlas.cogentco.com (154.54.85.245)  87.875 ms  89.383 ms 
 88.697 ms
 9  be3339.rcr21.iad03.atlas.cogentco.com (154.54.3.218)  90.027 ms
be3523.rcr22.iad03.atlas.cogentco.com (154.54.46.190)  94.035 ms
be3338.rcr21.iad03.atlas.cogentco.com (154.54.2.250)  94.773 ms
10  be3732.agr12.iad03.atlas.cogentco.com (154.54.88.58)  93.681 ms
be3768.agr11.iad03.atlas.cogentco.com (154.54.88.174)  98.066 ms
be3732.agr12.iad03.atlas.cogentco.com (154.54.88.58)  93.831 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * one.one.one.one (1.1.1.1)  8.541 ms  9.450 ms

traceroute to 1.0.0.1 (1.0.0.1), 64 hops max, 52 byte packets
 1  192.168.0.2 (192.168.0.2)  0.586 ms  0.191 ms  0.275 ms
 2  192.168.17.254 (192.168.17.254)  0.510 ms  0.374 ms  0.400 ms
 3  194.149.169.170 (194.149.169.170)  8.387 ms  7.985 ms  8.973 ms
 4  * * *
 5  * * *
 6  be2103.ccr42.par01.atlas.cogentco.com (154.54.61.21)  8.453 ms  8.672 ms  
8.589 ms
 7  be3593.rcr21.b019498-0.par01.atlas.cogentco.com (154.54.60.122)  8.453 ms  
8.845 ms
be3594.rcr21.b019498-0.par01.atlas.cogentco.com (154.54.60.126)  9.000 ms
 8  149.11.0.126 (149.11.0.126)  9.727 ms  13.034 ms  23.027 ms
 9  one.one.one.one (1.0.0.1)  8.561 ms  8.601 ms  9.406 ms


> Le 24 juin 2021 à 17:03, David Stéculorum  a écrit :
> 
> Pourrais-je avoir un traceroute depuis la meme source vers 1.0.0.1 ? 
> Regards,
> 
> David Stéculorum
> Network Engineering Manager EMEA
> 
> 
> 
> On Thu, Jun 24, 2021 at 3:59 PM Philippe ASTIER via frnog  <mailto:frnog@frnog.org>> wrote:
> Oui, mais 1.0.0.1 fonctionne encore.
> 
> > Le 24 juin 2021 à 16:44, Vincent Habchi  > <mailto:vinc...@geomag.fr>> a écrit :
> > 
> >> Apparemment, plusieurs machines sur le réseau Free 4g et fibre ne 
> >> parviennent plus à contacter le 1.1.1.1.
> > 
> > Je confirme depuis ma Freebox, je n’arrive pas à joindre 1.1.1.1
> > 
> > Air > traceroute 1.1.1.1
> > traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets
> > 1  192.168.0.254 (192.168.0.254)  9.683 ms  1.976 ms  2.393 ms
> > 2  194.149.164.64 (194.149.164.64)  4.953 ms  5.902 ms  5.302 ms
> > 3  * * *
> > 4  * * *
> > 5  be2103.ccr42.par01.atlas.cogentco.com 
> > <http://be2103.ccr42.par01.atlas.cogentco.com/> (154.54.61.21)  11.109 ms  
> > 5.656 ms  4.863 ms
> > 6  be2315.ccr31.bio02.atlas.cogentco.com 
> > <http://be2315.ccr31.bio02.atlas.cogentco.com/> (154.54.61.113)  18.264 ms
> >be2318.ccr32.bio02.atlas.cogentco.com 
> > <http://be2318.ccr32.bio02.atlas.cogentco.com/> (154.54.61.117)  18.294 ms  
> > 18.017 ms
> > 7  be2332.ccr42.dca01.atlas.cogentco.com 
> > <http://be2332.ccr42.dca01.atlas.cogentco.com/> (154.54.85.245)  122.223 ms
> >be2331.ccr41.dca01.atlas.cogentco.com 
> > <http://be2331.ccr41.dca01.atlas.cogentco.com/> (154.54.85.241)  89.846 ms
> >be2332.ccr42.dca01.atlas.cogentco.com 
> > <http://be2332.ccr42.dca01.atlas.cogentco.com/> (154.54.85.245)  84.787 ms
> > 8  be3338.rcr21.iad03.atlas.cogentco.com 
> > <http://be3338.rcr21.iad03.atlas.cogentco.com/> (154.54.2.250)  86.064 ms
> >be3523.rcr22.iad03.atlas.cogentco.com 
> > <http://be3523.rcr22.iad03.atlas.cogentco.com/> (154.54.46.190)  86.377 ms
> >be3339.rcr21.iad03.atlas.cogentco.com 
> > <http://be3339.rcr21.iad03.atlas.cogentco.com/> (154.54.3.218)  90.302 ms
> > 9  be2953.agr12.iad03.atlas.cogentco.com 
> > <http://be2953.agr12.iad03.atlas.cogentco.com/> (154.54.7.34)  86.609 ms
> >be3732.agr12.iad03.atlas.cogentco.com 
> > <http://be3732.agr12.iad03.atlas.cogentco.com/> (154.54.88.58)  86.259 ms
> >be2952.agr11.iad03.atlas.cogentco.com 
> > <http://be2952.agr11.iad03.atlas.cogentco.com/> (154.54.0.82)  90.510 ms
> > 10  * * *
> > 11  * * *
> > 12  * * *
> > […]
> > 
> > Vincent
> > 
> > 
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/ <http://www.frnog.org/>
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ <http://www.frnog.org/>


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Coupure Free -> 1.1.1.1

[Philippe ASTIER via frnog]

Oui, mais 1.0.0.1 fonctionne encore.

> Le 24 juin 2021 à 16:44, Vincent Habchi  a écrit :
> 
>> Apparemment, plusieurs machines sur le réseau Free 4g et fibre ne 
>> parviennent plus à contacter le 1.1.1.1.
> 
> Je confirme depuis ma Freebox, je n’arrive pas à joindre 1.1.1.1
> 
> Air > traceroute 1.1.1.1
> traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets
> 1  192.168.0.254 (192.168.0.254)  9.683 ms  1.976 ms  2.393 ms
> 2  194.149.164.64 (194.149.164.64)  4.953 ms  5.902 ms  5.302 ms
> 3  * * *
> 4  * * *
> 5  be2103.ccr42.par01.atlas.cogentco.com (154.54.61.21)  11.109 ms  5.656 ms  
> 4.863 ms
> 6  be2315.ccr31.bio02.atlas.cogentco.com (154.54.61.113)  18.264 ms
>be2318.ccr32.bio02.atlas.cogentco.com (154.54.61.117)  18.294 ms  18.017 ms
> 7  be2332.ccr42.dca01.atlas.cogentco.com (154.54.85.245)  122.223 ms
>be2331.ccr41.dca01.atlas.cogentco.com (154.54.85.241)  89.846 ms
>be2332.ccr42.dca01.atlas.cogentco.com (154.54.85.245)  84.787 ms
> 8  be3338.rcr21.iad03.atlas.cogentco.com (154.54.2.250)  86.064 ms
>be3523.rcr22.iad03.atlas.cogentco.com (154.54.46.190)  86.377 ms
>be3339.rcr21.iad03.atlas.cogentco.com (154.54.3.218)  90.302 ms
> 9  be2953.agr12.iad03.atlas.cogentco.com (154.54.7.34)  86.609 ms
>be3732.agr12.iad03.atlas.cogentco.com (154.54.88.58)  86.259 ms
>be2952.agr11.iad03.atlas.cogentco.com (154.54.0.82)  90.510 ms
> 10  * * *
> 11  * * *
> 12  * * *
> […]
> 
> Vincent
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] On ne peut plus se fare payer en Bitcoin

[Philippe ASTIER via frnog]

En fait, c’est du FUD pour décrédibiliser le Bitcoin.

Ils ne disent pas comment ils ont retrouvé l’argent, et par nature, ça veut 
dire qu’ils ont mis la main sur le portefeuille du destinataire, rien d’autre ! 
Et c’est pas parce que c’était du Bitcoin, mais probablement qu’ils ont réussi 
à remonter jusqu’à la machine du rançonneur et lui ont piqué son propre 
portefeuille… Je ne vois pas ce qu’ils auraient pu faire d’autre.

En fait, c’est même certain : "Stealing back a ransom »

Ils ont juste piraté la machine du méchant qui n’était pas très précautionneux.

Je ne vois pas ce que ça change en fait. Tant que des gens acceptent le BTC ou 
acceptent de le convertir...

> Le 8 juin 2021 à 03:14, Michel Py via frnog  a écrit :
> 
> Mince, on ne peut plus se faire payer en Bitcoin pour les transactions 
> douteuses sans se faire piquer.
> https://www.bbc.com/news/business-57394041
> Comment je vais faire pour me faire payer mes DVD de contrebande ?
> 
> Michel.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Freebox "pro" - ip publique - NAT - problèmes - ...

[Philippe ASTIER via frnog]

Ya pas de plafond pour les données chez nous, tu es ricin depuis trop longtemps.

L’IP fixe est incluse et gratuite (une seule). 
Nicolas a oublié deux numéros fixes gratuits inclus illimités, possibilité 
d’avoir une box en spare, et box rackable.

Le seul hic, c’est les limites du routeur pour le moment je dois dire, ça m’a 
refroidi. Le ASAP est … urgent.

Et pour te faire plaisir  :

Il ya même de l’IPv6…. Je savais que tu allais demander !


https://pro.free.fr

> Le 4 juin 2021 à 17:24, Michel Py via frnog  a écrit :
> 
 David Ponzone a écrit :
 La réponse « pour les 7Gbps en down » est interdite, même en vendredi.
 Bref, y a mieux, peut-être un peu plus cher, mais bien mieux.
> 
>>> Michel Py a écrit :
>>> J'ai une question de trolldi : combien ça coute, cette offre 7Gbps avec une 
>>> machinbox en mousse ?
> 
>> Nicolas GARNIER
>> 40€ HT sans engagement avec backup 4G + 1 SIM freemobile 4/5G
>> Ils annoncent les quelques modifs indispensables (DMZ, modif du subnet LAN), 
>> pour "ASAP Promis" ;-)
> 
> Woa maintenant j'en ai envie !!!
> Il y a un plafond mensuel pour les données ?
> On peut avoir une IP statique ? si oui, combien ?
> 
> 
> On peut faire du BGP ? :P
> 
> 
> Michel.
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Freebox "pro" - ip publique - NAT - problèmes - ...

[Philippe ASTIER via frnog]

OK, mea maxima culpa, c’est vrai qu’il faut que nous soyons précis.

En optique, on parle quand même plutôt de transceivers que de modem, et c’est 
bien parce qu’il n’y a pas une modulation bien complexe. (Pour les petits 
débits j’entends bien).

Bref, tout ça parce que la langue a évolué moins vite que les technos...
On s’est tous compris, c’est pas un bon sujet de troll, et on est juste jeudi :)



> Le 3 juin 2021 à 17:20, Nang Bat  a écrit :
> 
> Tout ce qui est avant le 40G/100G coherent c'est du NRZ ou du OOK ou
> assimilé, c'est certes assez naif comme modulation mais c'est pas
> cher, un codage léger par dessus et ça marche très bien pour pas un
> rond. Pour reprendre l'objection "qui n’existe absolument plus en
> optique", on fait quand même de la 64QAM en optique aujourd'hui.
> 
> Le jeu. 3 juin 2021 à 17:09, Richard Klein  a écrit :
>> 
>>> Et les 1310 nm, c'est pas une fréquence de porteuse ?
>> Pardon une longueur d'onde...
>> 
>> Une recherche sur Google sur "1310nm et modulation" montre qu'il y a plein
>> de descriptions  comme "direct light intensity modulation"
>> Donc une optique est bien un modem.
>> Un changement d'état d'un photon ou d'un électron serait donc une
>> modulation de son état et les destinataires pour l'encodage et le décodage
>> de l'information seraient des modems .
>> Les experts FRnog valident ?
>> 
>> Demain c'est vendredi...
>> 
>> Richard
>> Le jeu. 3 juin 2021 à 15:46, Erwan David  a écrit :
>> 
>>> 
>>>  Message d'origine 
>>> De : Erwan David [mailto:er...@rail.eu.org]
>>> 
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Freebox "pro" - ip publique - NAT - problèmes - ...

[Philippe ASTIER via frnog]

> Bonjour
> Modem cela veux dire modulation et démodulation donc cela s'applique à tous 
> type de techno . Les optiques font de la modulation/demodulation de lumière ! 
>  
> Richard

Ouais, espèce de petit trolleur…. :)

Après, dans un modem au sens historique du terme, on modulait une porteuse, 
chose qui n’existe absolument plus en optique. 
Une optique code le signal, mais ne le module pas.

Je sens que ça va troller dans tous les sens...


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Freebox "pro" - ip publique - NAT - problèmes - ...

[Philippe ASTIER via frnog]

> Tu sais qu’il y a pas de monopole sur le FTTH ? Même pas d’oligopole en fait, 
> presque partout.
> Donc tu peux travailler avec un autre acteur que Orange et Free, tu mettras 
> ton routeur, et la méthode de connexion ne changera pas (ça sera forcément du 
> PPPoE).

+1000. Il y a plein d’opérateurs sur le marché.

>> Autant dans le cas d'orange je peux comprendre la logique , vu qu'ils 
>> vendent aussi un service pro FTTO + RAD (qui a ses propres problèmes, mais 
>> bon) , autant pour Free je pige pas : ils ont tout intérêt à soit faire un 
>> très bon routeur, soit que l'on puisse s'en passer.
> 
> Ils ont jamais fait de B2B, pourquoi ils seraient bons dès le premier jour. 
> Et laisser le client mettre son routeur, quand tu gères des masses de 
> clients, c’est le début des emmerdes.


Oui, cela dit, je suis surpris, j’ai passé pas mal de temps à parler reverse 
DNS avec le support téléphonique (mon interlocutrice ne savait pas de quoi il 
s’agissait), elle a écouté, s’est renseignée, et m’a confirmé que c’était en 
développement.

Ils écoutent, autant leur remonter.

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Freebox "pro" - ip publique - NAT - problèmes - ...

[Philippe ASTIER via frnog]

Tu voulais dire « bridge ». Modem, ça implique qu’il y a une ligne analogique…

Sur les Freebox GP, tu gardes le téléphone et la TV en bridge, ça ne gêne pas.

Sincèrement, si on a un DMZ et un NAT fonctionnel et/ou des routes statiques en 
prime, c’est pas dramatique de ne pas porter l’IP publique.

J’ai pas ma de clients qui ont des FTTH Pro ou GP derrière Freebox et Livebox, 
et ça ne pose aucun souci pour d’avoir un autre routeur derrière qui fait le 
job, y compris pour des services entrants, des tunnels IPSec, voire même 
 du SD-WAN ! . OK, on perds un peu de latence, OK, il y a des 
implantations de NAT-T qui sont pourries, mais on peut s’en sortir.

En revanche du SNAT en entrant, c’est criminel. Tu fais ça sur le port 25 et 
c’est la porte ouverte à de l’Open Relay. C’est inadmissible.

> Le 3 juin 2021 à 14:59, Wallace  a écrit :
> 
> Le mode modem tu le branches sur ton firewall c'est le firewall qui porte les 
> ip v4 et v6 publiques.
> 
> Mais c'est clairement les fonctionnalités tel / backup 4G qui empêche cela 
> même si on devrait pouvoir choisir comme sur freebox où en mode modem on se 
> prive du tel / tv / fonctionnalité nas et autre de la box.
> 
> Le 03/06/2021 à 14:52, Philippe ASTIER a écrit :
>> « Mode modem «  ? Je ne comprends pas.
>> 
>> Le souci, c’est que 7 Gb/s down, 1 Gb/s up, backup 4G intégré, spare 
>> disponible, rackable, etc… ça laisse clairement ouvert sur beaucoup plus que 
>> les TPE, et ça conviendrait à beaucoup d’entreprises. D’ailleurs, pour les 
>> TPE et indépendants, autant prendre une box grand public pour le coup… 
>> 
>> Mais pas si le routeur nous empêche de travailler.
>> 
>> Ils n’ont qu’à faire un mode « routeur expert » en option, et puis ça fait 
>> le job.
>> 
>> 
>>> Le 3 juin 2021 à 14:44, Wallace  
>>> <mailto:wall...@morkitu.org> a écrit :
>>> 
>>> 
>>> Le 03/06/2021 à 13:18, Philippe ASTIER via frnog a écrit :
>>>> Free Semi-Pro en fait… 
>>>> 
>>> Ce n'est pas du tout une box pro, confirmation par une personne en
>>> interne que la box ne peut même pas faire de mode modem.
>>> 
>>> Même les freebox grand public font le mode modem, c'est incompréhensible
>>> de ne pas avoir cette fonctionnalité.
>>> 
>>> Après dans les communications on voit bien que l'usage prévu pour cette
>>> box "pro" est pour les TPE et les indépendants, ce n'est clairement pas
>>> pour mettre derrière sur un wan d'un firewall.
>>> 
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/ <http://www.frnog.org/>


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Freebox "pro" - ip publique - NAT - problèmes - ...

[Philippe ASTIER via frnog]

« Mode modem «  ? Je ne comprends pas.

Le souci, c’est que 7 Gb/s down, 1 Gb/s up, backup 4G intégré, spare 
disponible, rackable, etc… ça laisse clairement ouvert sur beaucoup plus que 
les TPE, et ça conviendrait à beaucoup d’entreprises. D’ailleurs, pour les TPE 
et indépendants, autant prendre une box grand public pour le coup… 

Mais pas si le routeur nous empêche de travailler.

Ils n’ont qu’à faire un mode « routeur expert » en option, et puis ça fait le 
job.


> Le 3 juin 2021 à 14:44, Wallace  a écrit :
> 
> 
> Le 03/06/2021 à 13:18, Philippe ASTIER via frnog a écrit :
>> Free Semi-Pro en fait… 
>> 
> Ce n'est pas du tout une box pro, confirmation par une personne en
> interne que la box ne peut même pas faire de mode modem.
> 
> Même les freebox grand public font le mode modem, c'est incompréhensible
> de ne pas avoir cette fonctionnalité.
> 
> Après dans les communications on voit bien que l'usage prévu pour cette
> box "pro" est pour les TPE et les indépendants, ce n'est clairement pas
> pour mettre derrière sur un wan d'un firewall.
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Freebox "pro" - ip publique - NAT - problèmes - ...

[Philippe ASTIER via frnog]

A priori, ce ne sont que des règles de Firewall, et ça s’appelle forcément NAT, 
pas de redirection de port !

Free Semi-Pro en fait… 

Je suis surpris par les trucs basiques qui manquent et que mêmes les autres 
Freebox font (parfois) : bridge, DMZ, changement de plage DHCP, pas de route 
statique, pas de reverse DNS personnalisable… On est en 2021 ?

Je pense qu’il serait bon de se lâcher sur le Github qui a été monté 
(ci-dessous) et qu’on râle chez XN...

https://github.com/LaFibre-info/Freepro/issues 
<https://github.com/LaFibre-info/Freepro/issues>



> Le 3 juin 2021 à 12:48, David Ponzone  a écrit :
> 
> Yep SNAT confirmé par le thread 
> https://lafibre.info/free-pro/parametrage-avance-de-la-freebox-pro/ 
> <https://lafibre.info/free-pro/parametrage-avance-de-la-freebox-pro/>
> 
> Ceci dit, je suppose que tu voulais que ce site soit le hub du VPN, ce qui 
> est surprenant.
> Mais tu dois pouvoir t’en sortir en renvoyant les ports UDP 500/4500 (si y a 
> pas de SNAT sur un port forward….).
> 
> Ou alors, si c’est un site distant, tu le déclares en client pur, c’est lui 
> qui monte le tunnel, auquel cas pas de souci si ton routeur supporte le 
> NAT-Traversal, ce qui fonctionnement très très bien en IKEv2.
> 
> J’ai raté un truc ou une contrainte ?
> 
>> Le 3 juin 2021 à 12:24, Laurent CARON  a écrit :
>> 
>> 
>> Le 03/06/2021 à 12:18, Philippe ASTIER via frnog a écrit :
>>> Super bizarre.
>>> 
>>> Et si tu ne laisses que la DMZ, sans aucune redirection de port ??
>> 
>> Tu ne peux pas laisser que la DMZ.
>> 
>> La DMZ s'obtient via la manip effectuée 
>> (https://support-pro.free.fr/est-ce-que-la-freebox-prevoit-le-mode-dmz/), la 
>> freebox pro fait donc du SNAT pour les connexions WAN -> LAN "dans mon dos".
>> 
>> Il n'y a pas à proprement parler de DMZ...
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Freebox "pro" - ip publique - NAT - problèmes - ...

[Philippe ASTIER via frnog]

Je n’ai encore jamais vu la conf de la Freebox Pro, CQFD

Déjà, pas de DMZ…. WTF ? C’est une blague ?
Mais en plus imposer du SNAT sur une redirection de port….. c’est encore plus 
une blague.

Dire que je les ai appelés hier pour savoir si on pouvait paramétrer le 
reverse-DNS (réponse : pas encore, mais c’est en cours de dev)..

Mais là c’est même pas un routeur basique. La première box qui ne sache pas 
faire de DMZ !


Et sinon, on peut déclarer des routes statiques, ou pas non plus ?


> Le 3 juin 2021 à 12:22, Laurent CARON  a écrit :
> 
> 
> Le 03/06/2021 à 12:08, Philippe ASTIER via frnog a écrit :
>> Alors c’est curieux, Freebox Pro ou pas, avoir ton routeur en DMZ devrait 
>> suffire, pas besoin de redirection de port d’aucune sorte.
>> 
>> Après, tout dépend de ton routeur et de celui que tu as en face.
>> 
>> Fortinet, Mikrotik, Edgerouter, Juniper je m’en suis toujours sorti 
>> (derrière LiveBox ou Freebox, avec ou sans NAT). Avec d’autres routeurs, 
>> (UDM-Pro chez Ubiquiti par exemple), c’est pas possible, parce que tu ne 
>> peux pas changer l’IP Source que tu présentes.
>> 
>> Tu peux nous en dire un peu plus sur le setup ?
> 
> Le setup est le suivant:
> 
> 
> Fibre Free === ONU Free === (@IP publique) Freebox pro (@192.168.10.254)  
> (@192.168.10.1) PC linux
> 
> La freebox pro ne dispose pas de vraie DMZ, mais propose de rediriger des 
> ports depuis l'interface.
> 
> J'ai donc redirigé tout ce qui vient d'une source '*' vers une destination 
> '*' vers l'IP LAN: 192.168.10.1
> 
> 
> Conditions de test:
> 
> Client (@IP publique) === Internet === Fibre Free === ONU Free === (@IP 
> publique) Freebox pro (@192.168.10.254)  (@192.168.10.1) PC linux
> 
> La redirection de port est bien fonctionnelle car j'ai bien accès depuis 
> l'exterieur au PC linux (ssh), _mais_ l'IP source présentée sur celui-ci est 
> l'IP de la box et non l'IP publique du client.
> 
> La box fait donc du SNAT depuis le WAN vers le LAN (alors que ça n'est pas ce 
> que je lui demande...ou alors je n'en comprend pas le fonctionnement).
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Freebox "pro" - ip publique - NAT - problèmes - ...

[Philippe ASTIER via frnog]

Super bizarre.

Et si tu ne laisses que la DMZ, sans aucune redirection de port ??

> Le 3 juin 2021 à 12:13, Laurent CARON  a écrit :
> 
> 
> Le 03/06/2021 à 11:54, David Ponzone a écrit :
>>> Le 3 juin 2021 à 11:47, Laurent CARON  a écrit :
>>> 
>>> Bonjour,
>>> 
>>> J'ai une freebox pro qui devait me servir à monter des tunnels VPN IPSEC 
>>> (entre autres).
>>> 
>>> La solution la plus simple (la box ne permettant pas de récupérer l'IP 
>>> publique sur mon routeur) est de mettre mon routeur en DMZ (comme sur une 
>>> livebox par exple).
>>> 
>>> Malheureusement la redirection de ports sur la freebox pro ne semble pas 
>>> fonctionner (confirmé par wireshark) comme attendu, celle-ci envoie son @IP 
>>> comme étant la source.
>>> 
>>> 11:44:26.290398 IP 192.168.10.1.22 > 192.168.10.254.29573: Flags [P.], seq 
>>> 565688:565900, ack 289, win 501, options [nop,nop,TS val 3978138866 ecr 
>>> 347808068], length 212
>>> 11:44:26.29 IP 192.168.10.254.29573 > 192.168.10.1.22: Flags [.], ack 
>>> 562932, win 3818, options [nop,nop,TS val 347808088 ecr 3978138849], length >>> 0
>>> 
>>> alors que la connexion est initiée depuis une @IP publique côté WAN.
>> 192.168.10.1 c’est ta box donc ? Et tu as tenté d’accéder au port 29573 de 
>> l’IP publique ?
>> Je trouve bizarre qu’elle fasse du srcnat sur le traffic entrant, en prenant 
>> 22 comme port source…
>> 
> Bonjour David,
> 
> 192.168.10.1 c'est le PC qui fait tourner wireshark (IP renseignée dans la 
> console free comme "DMZ").
> 
> 192.168.10.254 c'est la BOX.
> 
> Plus parlant et cette fois ci les échanges en entier (connexion sur le port 
> 23) depuis une @ip externe à la freebox pro à destination de son IP publique:
> 
> root@grml ~ # tcpdump -ni eth0 port 23
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 12:11:50.180184 IP 192.168.10.254.28780 > 192.168.10.1.23: Flags [S], seq 
> 1882626105, win 65535, options [mss 1460,sackOK,TS val 349451991 ecr 
> 0,nop,wscale 9], length 0
> 12:11:50.180265 IP 192.168.10.1.23 > 192.168.10.254.28780: Flags [S.], seq 
> 1919515353, ack 1882626106, win 65160, options [mss 1460,sackOK,TS val 
> 3979782756 ecr 349451991,nop,wscale 7], length 0
> 12:11:50.184778 IP 192.168.10.254.28780 > 192.168.10.1.23: Flags [.], ack 1, 
> win 128, options [nop,nop,TS val 349451997 ecr 3979782756], length 0
> 12:11:52.816443 IP 192.168.10.254.28780 > 192.168.10.1.23: Flags [P.], seq 
> 1:9, ack 1, win 128, options [nop,nop,TS val 349454627 ecr 3979782756], 
> length 8
> 12:11:52.816516 IP 192.168.10.1.23 > 192.168.10.254.28780: Flags [.], ack 9, 
> win 509, options [nop,nop,TS val 3979785392 ecr 349454627], length 0
> 12:11:53.736165 IP 192.168.10.254.28780 > 192.168.10.1.23: Flags [P.], seq 
> 9:12, ack 1, win 128, options [nop,nop,TS val 349455547 ecr 3979785392], 
> length 3
> 12:11:53.736224 IP 192.168.10.1.23 > 192.168.10.254.28780: Flags [.], ack 12, 
> win 509, options [nop,nop,TS val 3979786312 ecr 349455547], length 0
> 
> L'IP publique source de la connexion est bien remplacée par l'IP privée de la 
> freebox :(
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ 

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Freebox "pro" - ip publique - NAT - problèmes - ...

[Philippe ASTIER via frnog]

Alors c’est curieux, Freebox Pro ou pas, avoir ton routeur en DMZ devrait 
suffire, pas besoin de redirection de port d’aucune sorte.

Après, tout dépend de ton routeur et de celui que tu as en face.

Fortinet, Mikrotik, Edgerouter, Juniper je m’en suis toujours sorti (derrière 
LiveBox ou Freebox, avec ou sans NAT). Avec d’autres routeurs, (UDM-Pro chez 
Ubiquiti par exemple), c’est pas possible, parce que tu ne peux pas changer 
l’IP Source que tu présentes.

Tu peux nous en dire un peu plus sur le setup ?

> Le 3 juin 2021 à 11:47, Laurent CARON  a écrit :
> 
> Bonjour,
> 
> J'ai une freebox pro qui devait me servir à monter des tunnels VPN IPSEC 
> (entre autres).
> 
> La solution la plus simple (la box ne permettant pas de récupérer l'IP 
> publique sur mon routeur) est de mettre mon routeur en DMZ (comme sur une 
> livebox par exple).
> 
> Malheureusement la redirection de ports sur la freebox pro ne semble pas 
> fonctionner (confirmé par wireshark) comme attendu, celle-ci envoie son @IP 
> comme étant la source.
> 
> 11:44:26.290398 IP 192.168.10.1.22 > 192.168.10.254.29573: Flags [P.], seq 
> 565688:565900, ack 289, win 501, options [nop,nop,TS val 3978138866 ecr 
> 347808068], length 212
> 11:44:26.29 IP 192.168.10.254.29573 > 192.168.10.1.22: Flags [.], ack 
> 562932, win 3818, options [nop,nop,TS val 347808088 ecr 3978138849], length 0
> 
> alors que la connexion est initiée depuis une @IP publique côté WAN.
> 
> Utilisez-vous des Freebox pro ? Avez-vous rencontré ce genre de problème ?
> 
> Merci,
> 
> Laurent
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Retour sur UniFi 6 Long-Range Access Point

[Philippe ASTIER via frnog]

Bon pour mémoire, la discussion partait du Wifi, donc le plus souvent 100 mW, 
très souvent indoor, alors sauf à être vraiment collé à l’aéroport, ça devrait 
pas poser de soucis.

Les bandes n’ont pas été choisies au hasard, et le DFS, il me semble que c’est 
juste obligatoire, donc les précautions sont prises.


Après, le faisceau extérieur site-à-site régulièrement coupé, c’est plus du 
tout la même catégorie de ce règles, et l’intégrateur devrait savoir / aurait 
du le voir.

> Le 21 avr. 2021 à 10:01, Vincent Habchi  a écrit :
> 
> 
>> Attention à ne pas confondre les radars météo (qui opèrent autour de 
>> 5650Mhz) avec les radars de détection d'aéronefs qui opèrent à des 
>> fréquences biens plus hautes et qui  aujourd'hui, avec l'ADS-B sont un peu 
>> moins utiles sauf autour des aéroports .
> 
> Ah, intéressant. Je ne savais pas que c’était les radars météo dans cette 
> bande. Merci de l’info.
> 
> Quant aux radars aéronautiques, détrompe-toi. Il y en a (civils et 
> militairesà sur 1200 MHz (raison pour laquelle cette bande n’a jamais pu être 
> vraiment utilisée par les radioamateurs malgré l’allocation secondaire dont 
> ils bénéficient) – si je me souviens bien, le radar de Dammartin-en-Goële, 
> qui dessert Roissy, est à 1260 MHz (plus ou moins). C’était le gros bazar 
> pendant un temps dans ce segment de fréquences, parce qu’il y a aussi le 
> signal L1 du GPS dedans, à des puissances négligeables.
> 
> Et tu as même des radars dits « trans-horizon » qui opèrent en décamétrique !
> 
>> Concernant les radars météo par contre c'est très très problématique.
>> Le problème est que ces radars ont une sensibilité extrême, donc une borne 
>> wifi dans l'axe à plus de 100km peux perturber la détection météo.
> 
> Ouais, enfin, à ce niveau là, c’est clairement le régulateur et les 
> organisations de normalisation internationales qui sont à blâmer (ITU, 
> CEPT…). On n’autorise pas une application scientifique et une application 
> grand public sur la même bande de fréquence. C’est totalement incohérent. 
> Imagine qu’on mette des émetteurs FM grand public dans les bandes réservées à 
> la radio-astronomie…
> 
> D’un autre côté, utiliser du WiFi sur un château d’eau, comme l’article dont 
> tu as donné le lien décrit, c’est stupide.
> 
> Bref, comme d’habitude, les torts sont partagés. Mais cela révèle quand même 
> le faible niveau de certains ingénieurs et/ou techniciens en hyperfréquences. 
> L’exemple précédent à Strasbourg en est une autre bonne illustration : quand 
> on a des coupures périodiques sur un faisceau hertzien, la première chose à 
> faire est de louer un analyseur de spectre et regarder ce qui se passe…
> 
> V.
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Retour sur UniFi 6 Long-Range Access Point

[Philippe ASTIER via frnog]

Ben oui, mais 30 Mb / user sur  20/40 user par AP, fais le calcul.. On 
s’approche quand même vite du Gb/s !

Sur le plus que 1 Gb/s par port, Ubiquiti est en retard. Ils viennent juste de 
sortir leur premier switch PoE 24 ports 2.5 Gb/s. Le pire c’est qu’ils disent 
bien que c’est le switch parfait pour des APs… wifi 6.

Bref, ça va venir sous peu je pense.

> Le 20 avr. 2021 à 18:39, David Ponzone  a écrit :
> 
> Tu peux avoir besoin de plus d’1Gbps en crête sur un AP (quoique en dehors du 
> Stade de France….) mais pas pour un seul user.
> Si un user nomade a 20/30Mbps en WIFI, ça ira.
> Après si c’est du WIFI qui vient remplacer l’ethernet, c’est un autre 
> problème et vu l’économie de câblage que ça représente, ça mérite bien de 
> densifier niveau AP.
> 
>> Le 20 avr. 2021 à 18:33, Philippe ASTIER  a 
>> écrit :
>> 
>> Ben le truc c’est qu’on commence à déployer des bureaux en wifi-only, avec 
>> des plateaux denses.
>> Bon après c’est certain que pour chaque AP il n’y a pas forcément besoin de 
>> 1 Gb/s.
>> 
>> Mais je vois des AP facilement tirer 300-400 Mb/s en continu.
>> 
>> Après, grâce à l’année qui vient de s’écouler, on met les gens en remote, 
>> c’est super efficace pour gérer la BP du wifi ;P
>> 
>>> Le 20 avr. 2021 à 18:27, David Ponzone  a écrit :
>>> 
>>> De toute façon, qui a besoin de 1Gbps de BP en wifi….
>>> 
 Le 20 avr. 2021 à 18:06, Michel Py via frnog  a écrit :
 
> Wilfried Tidas a écrit :
> après je me posait la question surtout pour l'utilisation des spectres. 
> Il faut donc mieux les set a la main ?
 
 Sur un campus de grande dimensions, c'est ce que je fais; pas de MIMO.
 Le problème de MIMO, c'est que au final on a plusieurs bornes et clients 
 qui se battent pour la même fréquence, et c'est pas glop.
 Avec MIMO, on a refait la même connerie qu'en 2.4 GHz : les canaux qui se 
 recouvrent (en 2.4 GHz, en réalité il n'y a que 3 canaux : 1, 6, et 11).
 
 MIMO c'est très bien au milieu de la cambrousse car on peut effectivement 
 utiliser tous les canaux en même temps et donc avoir la vitesse maximum, 
 mais en milieu dense on en revient toujours au même problème de base : 
 quelle largeur de spectre on alloue à combien de clients. Moi je préfère 
 la méthode déterministe : même si la bande passante maximum est plus 
 faible, j'alloue 1 canal ou 2 à une borne, comme ça elle bave pas sur la 
 fréquence des bornes proches.
 
 Michel.
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>> 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Retour sur UniFi 6 Long-Range Access Point

[Philippe ASTIER via frnog]

Ben le truc c’est qu’on commence à déployer des bureaux en wifi-only, avec des 
plateaux denses.
Bon après c’est certain que pour chaque AP il n’y a pas forcément besoin de 1 
Gb/s.

Mais je vois des AP facilement tirer 300-400 Mb/s en continu.

Après, grâce à l’année qui vient de s’écouler, on met les gens en remote, c’est 
super efficace pour gérer la BP du wifi ;P

> Le 20 avr. 2021 à 18:27, David Ponzone  a écrit :
> 
> De toute façon, qui a besoin de 1Gbps de BP en wifi….
> 
>> Le 20 avr. 2021 à 18:06, Michel Py via frnog  a écrit :
>> 
>>> Wilfried Tidas a écrit :
>>> après je me posait la question surtout pour l'utilisation des spectres. Il 
>>> faut donc mieux les set a la main ?
>> 
>> Sur un campus de grande dimensions, c'est ce que je fais; pas de MIMO.
>> Le problème de MIMO, c'est que au final on a plusieurs bornes et clients qui 
>> se battent pour la même fréquence, et c'est pas glop.
>> Avec MIMO, on a refait la même connerie qu'en 2.4 GHz : les canaux qui se 
>> recouvrent (en 2.4 GHz, en réalité il n'y a que 3 canaux : 1, 6, et 11).
>> 
>> MIMO c'est très bien au milieu de la cambrousse car on peut effectivement 
>> utiliser tous les canaux en même temps et donc avoir la vitesse maximum, 
>> mais en milieu dense on en revient toujours au même problème de base : 
>> quelle largeur de spectre on alloue à combien de clients. Moi je préfère la 
>> méthode déterministe : même si la bande passante maximum est plus faible, 
>> j'alloue 1 canal ou 2 à une borne, comme ça elle bave pas sur la fréquence 
>> des bornes proches.
>> 
>> Michel.
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Retour sur UniFi 6 Long-Range Access Point

[Philippe ASTIER via frnog]

Oui, mais pas nature même, les canaux 5 GHz ne se recouvrent pas, c’est fait 
pour !

C’est dommage d’avoir des vais bornes qui font du MU-MIMO (entre autre) avec 
des débits cumulés qui peuvent dépasser le Gb/s, et qui ne savent pas le faire 
côté Ethernet.
Tous les concurrents le font déjà.

> Le 20 avr. 2021 à 17:03, Michel Py via frnog  a écrit :
> 
>> Wilfried Tidas a écrit :
>> Je souhaites avoir un retour sur les performances long terme des bornes 
>> Unifi wifi 6 ou les
>> bornes Unifi en général dans un environement  d'entreprises assez larges 
>> (300-500 personnes).
> 
> Satisfait ! Pas encore fait de WiFi 6, ceci dit. Pour ce qui est du 
> multi-gig, je ne fais pas de toute façon : il faut allouer une partie très 
> importante du spectre à chaque borne, je préfère mettre les canaux à la main, 
> pour qu'ils ne se recouvrent pas.
> 
> Michel.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Retour sur UniFi 6 Long-Range Access Point

[Philippe ASTIER via frnog]

Les interfaces Ethernet des Access Points Wifi 6 d’Ubiquiti sont pour le moment 
toutes uniquement en Gigabit.

Pas de 2.5, 5 ou 10 Gb/s.

En tout cas, c’est dans les spécifications, et si c’était le cas, je pense 
qu’ils le mettraient en avant !

Les LAGs sont supportés sur quelques modèles Wifi 5 (exemple : UAP-HD), mais là 
non plus sur aucun modèle Wifi 6.

> Le 20 avr. 2021 à 16:51, Ludovic LACOSTE  a écrit 
> :
> 
> Qu'est-ce que tu appelles multi gig? J'en ai déployé récemment et les traces 
> snmp semblaient ne pas conforter ton analyse ?
> 
> Téléchargez Outlook pour Android<https://aka.ms/ghei36>
> 
> 
> From: frnog-requ...@frnog.org  on behalf of Philippe 
> ASTIER via frnog 
> Sent: Tuesday, April 20, 2021 4:43:44 PM
> To: Wilfried Tidas ; frnog-t...@frnog.org 
> 
> Subject: Re: [FRnOG] [TECH] Retour sur UniFi 6 Long-Range Access Point
> 
> Très bien, en revanche, multi-gig n’est supporté sur aucun AP Unifi…
> Dommage de promettre plusieurs Gb/s sur une seule interface Gb. Il n’y a même 
> pas encore de modèle avec agrégation.
> 
> Ils vont y venir, mais pas encore au catalogue, même en early access.
> 
>> Le 20 avr. 2021 à 15:52, Wilfried Tidas  a écrit :
>> 
>> Hello le frnog ,
>> 
>> Je souhaites avoir un retour sur les performances long terme des bornes 
>> Unifi wifi 6 ou les bornes Unifi en général dans un environement  
>> d'entreprises assez larges (300-500 personnes).
>> 
>> Merci à vous.
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Retour sur UniFi 6 Long-Range Access Point

[Philippe ASTIER via frnog]

Très bien, en revanche, multi-gig n’est supporté sur aucun AP Unifi… 
Dommage de promettre plusieurs Gb/s sur une seule interface Gb. Il n’y a même 
pas encore de modèle avec agrégation.

Ils vont y venir, mais pas encore au catalogue, même en early access.

> Le 20 avr. 2021 à 15:52, Wilfried Tidas  a écrit :
> 
> Hello le frnog ,
> 
> Je souhaites avoir un retour sur les performances long terme des bornes Unifi 
> wifi 6 ou les bornes Unifi en général dans un environement  d'entreprises 
> assez larges (300-500 personnes).
> 
> Merci à vous.
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] SBG1 : Nouvel incendie chez OVH ce soir

[Philippe ASTIER via frnog]

L’article parle d’un incendie ce soir cela dit.


> Le 19 mars 2021 à 21:35, Jarod G.  a écrit :
> 
> Encore plus si celles-ci étaient connectées à rien...
> Par contre apparemment pas de feu, vraiment ?
> 
> "Update March,19 9:30pm
> The batteries were in unused room, not used, not connected. We didn’t
> have the fire, but we had lot of smoke. The situation is under control
> now. Everybody is safe.
> 
> We stop the operation in SBG for this night. We will take the decision
> tomorrow."
> 
> https://twitter.com/olesovhcom/status/1373008716484726785
> 
>> Le 19/03/2021 à 21:31, Jarod G. via frnog a écrit :
>> Oles avait publié sur le sujet justement :
>> 
>> "Update March,15 9pm
>> 
>> We had the smoke in an unused room in SBG1. We shutdown SBG1+SBG4 & we
>> called the firefighters to identify the root cause. The firefighter
>> stopped the smoke which came from the batteries that we don’t use. More
>> info tomorrow. We stop the operation this night."
>> 
>> https://twitter.com/olesovhcom/status/1373001710801653767
>> 
>> La question étant, pourquoi ces batteries auraient pris feu si elles
>> étaient "inutilisées" ?
>> 
>>> Le 19/03/2021 à 21:28, Philippe ASTIER via frnog a écrit :
>>> Incroyable.
>>> Je cite : "Le sinistre aurait touché 300 batteries de 25 kg sur le data 
>>> Center SBG1. « 
>>> 
>>> Beaucoup moins d’impact et incendie maîtrisé, c’est pour ça que j’ai mis 
>>> MISC.
>>> 
>>> 
>>> https://www.dna.fr/faits-divers-justice/2021/03/19/nouvel-incendie-chez-ovh 
>>> <https://www.dna.fr/faits-divers-justice/2021/03/19/nouvel-incendie-chez-ovh>
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>> 
>> 
> 
> -- 
> GPG : 71E5 89D2 ADA9 F401 56CE 4374 B11B 7C56 F111 C320
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [MISC] SBG1 : Nouvel incendie chez OVH ce soir

[Philippe ASTIER via frnog]

Incroyable.
Je cite : "Le sinistre aurait touché 300 batteries de 25 kg sur le data Center 
SBG1. « 

Beaucoup moins d’impact et incendie maîtrisé, c’est pour ça que j’ai mis MISC.


https://www.dna.fr/faits-divers-justice/2021/03/19/nouvel-incendie-chez-ovh 

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

Merci pour le calcul… faut que je dorme… 

Pour moi = HA = haute disponibilité = cluster avec de grosses contraintes.

Le problème c’est que le terme a dérivé, parce que la HA pour un serveur web, 
on peut tricher en multipliant les frontaux.

Au départ, la HA, c’était du cluster sur site avec de la bascule automatique en 
quelques secondes de manière automatique, et c’est pas le même jeu.

> Le 18 mars 2021 à 10:45, Francois Prems  a écrit :
> 
> Bonjour à tous,
> 
> Merci pour ce débat très intéressant et instructif.
> 
> Je veux juste apporter ma minuscule contribution en corrigeant une erreur 
> significative dans le contexte 
> 
> > 99,99% = 3,65 jours de downtime par an, ça commence déjà à faire beaucoup.
> 
> Non,  99,99% = 52 minutes de downtime par an.
> 
> (3.65 jours c'est 99% d'une année, pas 99.99%, qui est presque 1% de plus)
> 
> Et ma petite question sur un point qui semble au coeur des désaccords : 
> est-ce qu'un pro, qui est supposé savoir de quoi on parle etc... avait la 
> possibilité de savoir que le super HA vendu par ovh était monosite ? D'après 
> les infos de certains, j'ai l'impression qu'à moins d'aller creuser très 
> loin, cette info n'était pas accessible et tout laissait à penser que c'était 
> le cas (le fait que les SBG-x soient autant concentrés n'aidant pas).
> Perso, je n'aurais probablement pas imaginé devoir aller sur une carto 
> vérifier l'éloignement entre 2 DC pour anticiper un incendie. Car quelques 
> centaines de mètres suffisent normalement à se protéger assez certainement 
> d'une perte totale de données avec un backup minimal... 
> 
> François 
>  


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

> Tu te confrontes à tes propres contradictions : c'est aux prestas de
> prévoir les backups hors-site mais quand OVH te dit qu'il s'en occupe,
> tout d'un coup ça devient 'compliqué' ? Avec un réseau en propre ?

La responsabilité d’un professionnel, c’est de savoir comment est fait ce qu’il 
délègue à autrui.

Est-ce que tu as un contrat d’OVH qui te dit que les backups de ta solution 
étaient hors site ? Si oui, tu les traines au tribunal. Sinon… ben ya eu un 
trou dans la raquette, ou alors fallait pas signer. (Je me rends compte que tu 
dis après que tu étais en train de sortir, donc ce n’est pas forcément ta 
responsabilité initiale).

> Au risque de te vexer à nouveau (sans que ce soit le but), c'est ma
> définition de fan-boy, mais on peut ergoter longtemps juste sur ce point.

Je ne vais pas me vexer du tout. 

> Mon client n'attendait pas de la haute dispo sur une catastrophe
> pareille mais un backup restaurable, même à J+7, il aurait trouvé ça
> plutôt normal. TL;DR : le backup est spécifié dans le service NAS-HA.
> Après, ce que c'est exactement, on en sait pas et c'est justement là
> qu'on a fauté pour notre part.

« Le backup est spécifié ». J’ai pas lu les termes, ça dit quoi ? 
Ah pardon, tu as écrit que tu ne savais pas. Ben sans vouloir te vexer, fallait 
pas signer du tout. Mais moi je me contredis...

> On essaie toutefois de rester humbles et compatissants parce qu'un jour,
> ça va nous arriver.

L’humilité est importante dans nos métiers. On commet tous des erreurs par 
omissions ou excès de confiance, surtout que tout le monde pense que tout 
s’offre instantanément à 10 euros, et que tout est indestructible. C’est nier 
la réalité.

>> 99,99% = 3,65 jours de downtime par an, ça commence déjà à faire beaucoup.
> Tu connais les contraintes de dispo de mon client et ce qu'il a lui-même
> vendu à ses clients ?

Non. Je sais juste que 99,99%, ça fait classe, il y a beaucoup de chiffres. Je 
voulais juste faire remarquer que ça fait près de 3,65 jours de downtime. Si 
c’est pour faire de l’argent ça a un coût.

>> Tu es allé chez OVH pour le côté low-cost, difficile de s’en offusquer 
>> après. 
> Je n'ai pas dû être clair, désolé : j'étais en train de SORTIR un
> client, ce ne sont pas des choix que j'ai fait mais que je dois assumer
> quand même, c'est la vie ;-)


Ouais, c’est le pas de bol.
« Shit happens » 

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

+1000 au moins
Merci Stéphane, c’était exactement le but de mon premier message…

Le bashing ne fait rien avancer, et ne permet pas de retex.

L’offre d’OVH permet d’accéder rapidement à des services qu’on a du mal à 
trouver aussi simplement ailleurs.

Après, personne ne vous empêche de changer de crèmerie non plus.

> Le 18 mars 2021 à 10:16, Stéphane Rivière  a écrit :
> 
> Non messieurs, d'abord on ne s'étripe pas, on discute et je ressens le
> bashing OVH comme injuste par rapport à ce qu'offre OVH pour le prix.
> 
> Donc je prends le temps de basher les basheurs, dans le respect
> toutefois (chacun est libre de ses opinions, y compris de critiquer les
> critiqueurs, n'est-il pas ? ;)
> 
> Je ne suis pas un fan boy, ni ne réduit l'incendie d'un onduleur à un
> problème marketing. Facile de fermer le débat par des adjectifs ou
> d'accuser le marketing de tous les maux.
> 
> La critique est facile et il n'y a pas de honte à choisir la bourse si
> c'est leur choix, ni de changer leur nom si ça leur chante, ni de faire
> de la gratte et un album pour se faire plaisir... C'est leur droit
> d'entreprise et d'humains libres et le marché tranchera.
> 
> Je suis un tech qui a conscience de la difficulté de faire son métier de
> sysadmin et de l'extraordinaire complexité technique d'une entreprise
> comme OVH. La technique est faillible.
> 
> Je suppose qu'on fera un jour un procès à la nature parce qu'au bout, il
> y a la mort. Comme des enfants font déjà des procès à leurs parents
> parce qu'ils n'ont jamais demandé à naître.
> 
> Vous confondez le 'système parfait' qui n'existe pas avec un process
> d'évolution technique où les DC d'OVH tendent, à chaque génération, vers
> le meilleur, selon une approche d'action, réaction (retex), correction.
> 
> Musk fait pareil avec ses fusées. C'est l'approche à privilégier pour
> innover rapidement.
> 
> Vous confondez un accident industriel, qui aura un retex, avec le
> résultat d'une conception malveillante, comme le 737max.
> 
> Pour le reste Carpe Diem.
> 
> -- 
> Be Seeing You
> Number Six
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

> Honnêtement, je pense qu'il faut que vous sortiez des facteurs
> techniques et que l'on accepte collectivement que c'est le marketing qui
> est la cause principale d'une perte de données.

Euh on a écrit ça. 
Le marketing fait oublier à certains la réalité technique.
Ca n’empêche que les professionnels qui achètent doivent comprendre ce qu’ils 
achètent, en profondeur.

> Exemple : j'ai un client qui était en cours de migration sur une infra
> qu'on lui a monté chez nous : pas de bol, ce qui tournait bien, n'avait
> pas de soucis de perf ou de problème immédiat de redondance était à
> SBG2. des machines physiques avec une grosse partie du stockage en
> NAS-HA. Pourquoi on est passés à côté ? Parce que le service NAS-HA, il
> est vendu sur la page comme quasi-indestructible avec des SLA de malade
> en dispo, du backup, etc ...

La haute-disponibilité entre sites, c’est hors de prix et contraignant, parce 
que la bande passante et la latence sont durs à gérer, même avec les débits 
d’aujourd’hui.
Un NAS-HA, forcément, c’est sur un site, faut pas rêver. 

Bref. Un bâtiment, ça se détruit, la preuve. 
Donc ton NAS-HA il était destructible. Tout le monde l’oublie, certes, mais il 
fallait le documenter et comprendre si c’était un souci ou pas.

> 99,99% d'uptime garanti, pour du site vitrine, ça semblait bien coller,
> on s'est laissés avoir, on a pas creusé davantage et on a commencé à
> migrer à marche forcée les trucs qui étaient vraiment en danger.

99,99% = 3,65 jours de downtime par an, ça commence déjà à faire beaucoup.

> Avec tout le respect que j'ai pour Octave et ce qu'il a accompli ces 20
> dernières années, quand on démarre une boite dans un esprit low-cost, il
> est très difficile d'en sortir (cf le peering Free, par exemple), n'en
> déplaise aux fan-boys.

Tu es allé chez OVH pour le côté low-cost, difficile de s’en offusquer après. 
Le teme de fan-boy est assez insultant. J’ai des services chez OVH, chez 
d’autres, en fonction des contraintes et du coût.

OVH a un price-point intéressant, avec des risques, qu’on n’est pas forcé 
d’accepter.

> La chose positive dans tout ça, c'est que depuis, nos clients nous
> 'challengent' sur leurs PRA/PCA et on découvre plein de trucs qui ne
> vont pas ici et là. C'est très instructif.

Ah ben ça c’st cool. :)

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

Re-my bad…

Sur les photos, SBG1 est moins visible parce que plus petit.
Et SBG2, ça ressemble sacrément à des containers, mais c’est vrai qu’on 
remarque que c’est pas la même taille que les vrais qui sont à côté.

> Le 17 mars 2021 à 20:03, Vincent Tondellier via frnog  a 
> écrit :
> 
> Le Wednesday 17 March 2021 19:34:36 Philippe ASTIER via frnog a écrit :
>> Tout le monde savait que SBG2 était constitué de containers en free
>> cooling. 
> 
> 
> Ettt non ! 
> C'est comme le coup de la triple réplication ceph qui se transforme au fur et 
> a mesure en triple backup, c'est faux.
> 
> SBG1, SBG4 oui c'est des containers maritimes.
> SBG2 c'est (ou c'était) une tour avec patio en water/free cooling, mais en 
> dur, pas en containers.
> SBG3 c'est en dur aussi, mais une autre techno que SBG2.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

Ah yes, my bad, suis pas un spécialiste… J’ai lu trop vite.

Du coup, il y avait seulement 2 châssis alors pour les 44 fibres ? Ou un truc 
dans le genre ?


Schéma très risqué quand même, non ?






> Le 17 mars 2021 à 20:23, Hugues Voiturier  a écrit 
> :
> 
> 44 transpondeurs ? Non, on parle de châssis WDM, interconnectés entre eux. 
> 
> Donc une conf corrompue sur un membre du noeud peut tout corrompre.
> 
> Pourquoi avoir tout relié ? Parce que ça simplifie beaucoup le re-routage en 
> cas de fibercut.
> 
> Bref, pas de bol :)
> 
>> On 17 Mar 2021, at 20:20, Philippe ASTIER > > wrote:
>> 
>> Ouais. Il y a du détail (merci d’ailleurs !)
>> 
>> Mais 44 transpondeurs différents qui perdent leur conf en même temps, c’est 
>> un sacré drôle de bug.
>> 
>> Je lis que la « base de configuration copié2 3 fois sur 2 cartes de 
>> supervision différentes » a « DISPARU «  ? Pouf… baguette magique.
>> 
>> Il manque le détail de l’enquête qui a suivi avec le constructeur.
>> 
>> 
>> Tiens, ça fait d’ailleurs penser à ce qu’on fait dans des domaines sensibles 
>> (aéronautique, nucléaire, etc…) : ne pas mettre tous ses oeufs dans le même 
>> panier...
>> 
>>> Le 17 mars 2021 à 20:10, Hugues Voiturier >> > a écrit :
>>> 
 Le blackout de 2017 (je crois) me perturbe plus. 
 Je n’ai vu aucune explication sur l’arrêt simultané de 40 modules 100 Gb/s 
 qui coûtent je ne sais pas combien. C’est pas normal, corrigez-loi si je 
 me trompe hein…
>>> 
>>> Ca a été expliqué ici pourtant :
>>> 
>>> http://travaux.ovh.net/?do=details=28244 
>>> 
>> 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

Ouais. Il y a du détail (merci d’ailleurs !)

Mais 44 transpondeurs différents qui perdent leur conf en même temps, c’est un 
sacré drôle de bug.

Je lis que la « base de configuration copié2 3 fois sur 2 cartes de supervision 
différentes » a « DISPARU «  ? Pouf… baguette magique.

Il manque le détail de l’enquête qui a suivi avec le constructeur.


Tiens, ça fait d’ailleurs penser à ce qu’on fait dans des domaines sensibles 
(aéronautique, nucléaire, etc…) : ne pas mettre tous ses oeufs dans le même 
panier...

> Le 17 mars 2021 à 20:10, Hugues Voiturier  a écrit 
> :
> 
>> Le blackout de 2017 (je crois) me perturbe plus.
>> Je n’ai vu aucune explication sur l’arrêt simultané de 40 modules 100 Gb/s 
>> qui coûtent je ne sais pas combien. C’est pas normal, corrigez-loi si je me 
>> trompe hein…
> 
> Ca a été expliqué ici pourtant :
> 
> http://travaux.ovh.net/?do=details=28244



signature.asc
Description: Message signed with OpenPGP

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

> Je ne doute pas une seconde qu'il soit affecté et à différents niveaux.
> Je ne doute pas qu'ils vont apporter des améliorations aux DC. Tant mieux.
> Ceci dit, quand il y a eu le blackout réseau chez eux y a pas si
> longtemps, ça semblait impossible... On s'est dit, bon, ça c'est fait,
> on le verra plus jamais. Maintenant, ça..

Le blackout de 2017 (je crois) me perturbe plus.
Je n’ai vu aucune explication sur l’arrêt simultané de 40 modules 100 Gb/s qui 
coûtent je ne sais pas combien. C’est pas normal, corrigez-loi si je me trompe 
hein...

> Non, je ne crois pas. OVH est un acteur parmi d'autres sur un marché
> concurrentiel. S'ils n'étaient pas là on irait voir ailleurs.
> Je souhaite sincèrement qu'ils s'améliorent, mais qu'ils s'améliorent de
> façon proactive.

Tu as essayé de voir ailleurs ?

On ne peut pas tout anticiper.
Mais j’en reviens au PRA, qui doit comporter le plan « site détruit ». Tout le 
monde peut t’aider à traiter ce cas, même OVH.

> J'aurais bien aimé qu'ils aillent au devant des problèmes plutôt qu'on
> les subisse tous (eux et nous, les clients).
> C'est bien de tirer des leçons de ses erreurs, mais ce n'est pas suffisant.

Tous les cas ne se prévoient pas.

Quand tu écris ton plan, tu acceptes certains risques parce que ça finit par 
coûter trop cher.

Chez job-3 comme dirait quelqu’un, on avait un DC historique sur la côte Est, 
pas loin de New York. On se demandait où poser le deuxième DC, et on avait un 
site pas loin de Philadelphie. Cool, c’est loin, non ?
Ah ben oui, mais si jamais toute la côté est coupe (et c’est déjà arrivé) ? On 
gère la prod du groupe pour le monde, ça serait dommage de couper les usines en 
Europe… Parce que avoir ton DC qui tourne sur groupe tout seul alors qu’il n’y 
a plus de réseau...

Du coup, on a regardé pour faire plus loin, genre côté ouest. A l’époque, ça 
nous aurait coûté tellement cher en fibre noire (il y avait du volume), sans 
compter les problèmes de réplication, de latence, je t’en passe, que le 
business nous a dit : bon Philadelphie c’est bien. On a compris, au pire, on 
arrêtera toute la prod plusieurs jours s’il le faut.

Et c’était avant le 11 septembre...

Tant que tu ne sais pas combien te coûte tes pertes d’exploitation, tu ne peux 
pas faire de choix éclairé.


signature.asc
Description: Message signed with OpenPGP

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

> Je suis globalement d'accord avec ton message.

Ouf… de toute façon, je n’espérais pas détroner le frôleur en chef de l’autre 
côté de l’Atlantique :) J’ai renoncé.

> 
> Le 17/03/2021 à 17:57, Philippe ASTIER via frnog a écrit :
>> Je pense qu’OVH a une responsabilité sur l’absence de transparence sur le 
>> service exactement fourni, au moins pour une partie de ses services.
> 
> Ils ont également une responsabilité dans la façon dont ils ont conçu
> leurs propres DC et la sécurité qu'ils ont mis dedans/autour pour
> assurer les services qu'on leur achète.
> Ce n'est quand-même pas au client lambda d'expliquer au professionnel de
> l’hébergement comment il doit concevoir son DC.
> Et d'un autre côté flamber son DC n'a jamais été un standard dans la
> profession. Ça reste des exceptions.

Le problème c’est qu’on présente les Datacenters comme des bunkers 
indestructibles où tous les scenarios du monde sont prévus. 
Ben non. Il y a des tiers-1, 2, 3… avec des contraintes et des sécurités 
différentes, chez tous les opérateurs.

Tout le monde savait que SBG2 était constitué de containers en free cooling. 

Bref, assurer un service, oui. Contre quel niveau de risque, c’est là le flou.


> Pas de problème. Le mien "haut de gamme" payé au prix fort est peut-être
> juste à côté du tien. :)))
> As-t-on réellement l'assurance que quand on paye plus cher, les
> prestations suivent ? Pas sûr.
> Je laisse passer le nuage des fumées et je vais voir si OVH est capable
> d'apporter des précisions sur son organisation interne à un client
> "comme un autre" : où sont réellement les serveurs (surtout les PCI),
> comment sont aménagés les DC où ils se trouvent, quels sont les
> dispositifs anti-feu/inondation/radiations/etc.

Ben tu peux payer plus cher parce que tu as un plus gros serveur sans pour 
autant avoir des backups hors sites, c’est pas choquant en soi.

C’est pas une question de prix, c’est surtout de pouvoir poser la question de 
savoir ce qui est mis en pratique, et d’en accepter (ou pas) le risque.


J’ai mis une semaine à confirmer que mon VPS était sur SBG6 (enfin SBG3, vu que 
SBG6 est en openstack… bref), parce qu’il n’était juste plus listé sur la 
console du tout (en dehors de son IP).
C’est inadmissible. C’est pas une question de prix, j’ai le droit d’exiger de 
savoir où il est. Et si on ne me répond pas…. Ben j’ai le droit de partir, 
c’est la loi du marché.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

:)

J’ai oublié un point : un PRA pas testé, c’est comme s’il n’était pas écrit.
Un backup qu’on n’a pas essayé de restaurer, c’est comme si on n’en avait pas.

Alors quand on espère qu’avec une case à cocher on est couvert, ben… faut 
changer de métier.

> Le 17 mars 2021 à 17:56, Stéphane Rivière  a écrit :
> 
> 
>> C’est pas un avis à 2 cents en fait. Ca vaut beaucoup plus cher que ça. :)
>> D’autant que j’ai du me mettre à dos la moitié de la liste...
> 
> Mais FRnOG vaut mieux que ça :)))
> 
> Et merci pour ce message.
> 
> -- 
> Be Seeing You
> Number Six
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

Bon, d’abord, je vois que j’ai encore des lecteurs :)

Je pense qu’OVH a une responsabilité sur l’absence de transparence sur le 
service exactement fourni, au moins pour une partie de ses services.

Par exemple, quand on parle d’un triple backup des VPS, je pense qu’il vient 
naturellement à l’esprit de tout le monde que ce n’est pas sur le même site. 

Et on attend tous qu’OVH comprenne ce qui s’est passé, nous l’explique (aussi 
pour nos autres hébergeurs !), et prenne le mesures qu’il faut.

Moi je m’attends surtout à pouvoir savoir où est physiquement chacun des 
services que je paie, ce qui clairement n’était pas le cas.
Si Octave réagit bien, il va rajouter l’option backup hors site avec le coup 
associé d’ailleurs.


Maintenant, je veux aussi pouvoir acheter un serveur nu, sans backup, dans une 
case en carton pâte si c’est facturé le bon prix.

Le problème c’est la facilité du Clickodrome qui fait qu’un trois click et une 
CB on achète un service sans avoir lu le contrat et comprendre ce qu’on a 
acheté. Du coup, monter un service est trop facile. Vous imaginiez vraiment 
qu’à 10€/mois, vous aviez un serveur, de l’électricité, des backups, une 
connexion internet et aussi un bouton « PRA » peut-être ? Faut un peu garder 
les pieds sur terre. J’ai un VPS qui a eu chaud et qui redémarre semaine 
prochaine, mais je savais que je m’exposais à le perde...

Je pense qu’on va passer à la mode legal US : te faire 3 popups pour certifier 
que tu as bien lu le contrat (que bien entendu tu n’auras pas plus lu). Au 
moins, tu auras menti trois fois, et ça sera vraiment ta faute.


> Le 17 mars 2021 à 15:31, Artur  a écrit :
> 
> Salut,
> 
> Le 17/03/2021 à 14:41, Alexandre Archambault a écrit :
>> 
>> Si cet incident peut participer de la prise de conscience qu'il
>> appartient au professionnel d'organiser, le cas échéant en sachant
>> s'entourer de conseil extérieurs - il a tout à fait le droit de ne pas
>> tout maitriser - sa stratégie de sauvegarde, qui commence, en premier
>> lieu, par lire ce qu'il peut signer.
> 
> C'est un paragraphe qui s'adresse à OVH ? ;)
> 
> Je suis d'accord sur le fait que le client qui achète des prestations à
> OVH peut être un pro et savoir ce qu'il achète bien que rien n'a été
> fait pour informer le client sur l'organisation interne des services d'OVH.
> Mais quand je m'adresse à un pro comme OVH (enfin... c'est ce qu'ils
> disent partout), je ne m'attends pas à acheter un service à Mme Michu
> qui a mis un serveur dans une boite en carton avec les bandes de
> sauvegardes posées dessus.
> 
> Si le client peut avoir une part de la responsabilité dans la survie de
> ses données / de son activité dans une situation comme celle-ci, je ne
> dédouane pas du tout OVH de sa part de responsabilité à elle.
> D'ailleurs je ne dois pas avoir tout à fait tort car Oles a bien précisé
> dans ses vidéos qu'ils ont fait des choix discutables et qu'ils doivent
> améliorer des choses pour que ce genre de catastrophes (oui, de mon
> point de vue, ce n'est pas un incident) n'arrive plus ou en tout cas pas
> dans ces dimensions.
> 
> Pour ceux qui se demanderaient, je suis client d'OVH depuis bien
> longtemps à titre personnel et pro. J'ai plusieurs machines au SBG3 qui
> attendent gentiment qu'on veuille bien les rallumer et nos clients n'ont
> aucunement été impactés par le sinistre à SBG.
> Et ma situation ne change rien à mon avis sur cet affaire que j'ai
> brièvement exprimé ci-dessus.
> Sur le plan humain, je compatis, etc. Sur le plan pro, je pardonne rien.
> Et de mon point de vue, comme tout professionnel qui se respecte, les
> hébergeurs ont des responsabilités envers leurs clients qu'ils doivent
> assumer, je ne parle même pas de respect qu'on leur doit puisque ce sont
> eux qui font vivre lesdits hébergeurs.
> 
> -- 
> Cordialement,
> Artur
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

> Parce que prendre l'option payante pour les snapshots journaliers, en fait, 
> bah c'est juste de la merde en boite puisque c'est stocké à côté pour pouvoir 
> faire un restore en cas de panne mineure.
> Et ceux qui ont eu la chance d'avoir un backup FTP vers RBX, il semblerait 
> que ce soit juste "de la chance".
> Et quand en plus, lors des migrations (forcées) vers leur nouvelle 
> plateforme, on peut être basculé d'un bâtiment à l'autre sans aucun contrôle 
> dessus, lorsqu'on y réfléchit, ça ne donne pas trop envie de mettre tous ses 
> œufs chez OVH.

Je voudrais apporter mes 2 cents de bémol.

Un snapshot, c’est permet de se protéger des problèmes plus « logiques »  sur 
la machine, donc ce n’est absolument pas choquant pour moi que ce soit à côté, 
au contraire, le but est d’aller vite en supposant que le hardware n’a rien. 
Techniquement, un snapshot hors site, c’est pas très logique du tout.

Une sauvegarde, c’est déjà pas la même stratégie, et on peut aussi d’en avoir 
sur site, mais en ayant conscience qu’on n’a pas de protection en cas de 
sinistre physique. Ou même simplement d’indisponibilité du site.

Personne ne vous empêche d’avoir un snapshot sur site, un premier niveau de 
sauvegarde sur site et un deuxième sur un autre DC. C’est même probablement la 
meilleure chose à faire, OVH ou pas. Et de nombreux clients d’OVH, qui avaient 
adopté cette stratégie sont repartis en quelques heures.


C’est la base de notre métier et de l’écriture d’un PRA. Savoir quels sont les 
risques, combien ils coûtent, et comment les mitiger ou s’en protéger.

Donc, je ne reste pas d’accord, OVH ne fait pas de « merde en boite », et 
permet d’avoir le niveau de sauvegarde qu’on l’on veut en fonction des risques 
dont ont veut se protéger, au prix que l’on accepte de payer. OVH a toute les 
technos disponibles pour mettre en oeuvre un PRA complexe. C’est même peut-être 
beaucoup plus transparent que chez Azure ou AWS.


Donc, j’en ai marre qu’on charge OVH parce que certains « pros » ne se sont 
juste jamais préoccupé de la base de leur métier : savoir où sont leurs 
données, comment elle sont protégées, et comment faire en cas de sinistre. 

Je suis très curieux de voir les sociétés qui ont utilisé OVH en « clickodrome 
à pas cher » se défendre que leurs clients finaux vont leur demander où sont 
passées leurs données. 


Après, je suis pas naïf, qu’OVH pousse le marketing à nous faire croire que « 
tout va bien madame la marquise », ça se discute. Mais si l’infra d’OVH (ou de 
qui que ce soit d’autre) sert à faire de l’argent, il faut le faire 
sérieusement, en se posant les questions AVANT que le sinistre se produise, et 
pas en pleurant après que…. Ah mais ils ne m’ont pas dit ? Ca passe pour du 
grand public, pas pour du professionnel.


C’est pas un avis à 2 cents en fait. Ca vaut beaucoup plus cher que ça. :)
D’autant que j’ai du me mettre à dos la moitié de la liste...


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] OVH WHOIS information leak ?

[Philippe ASTIER via frnog]

Bon, ça n’a rien à voir avec le souci de SBG, et sur mon domaine, ça date de 
l’an dernier, un changement le 18 février 2020. Bizarre.

En tout cas, OVH ne respecte pas le setting de la console, et ce n’est pas 
normal.

Merci une nouvelle fois !

> Le 12 mars 2021 à 14:57, Philippe ASTIER via frnog  a écrit :
> 
> Je vais regarder, je trouve ça aussi étrange.
> 
> Disons qu’on me le fait remonter le lendemain. C’était peut-être là avant, ou 
> pas. Mais je ne suis pas le seul, j’ai des exemples en dehors de mes domaines.
> 
> Merci à tous ceux qui regardent en tout cas.
> 
> J’ai un ticket chez OVH en cours sur le sujet, mais ils sont manifestement 
> sous l’eau, et on comprend bien...
> 
>> Le 12 mars 2021 à 14:54, Charley SEDEAU  a écrit :
>> 
>> Bizarre, sur les .fr c'est l'AFNIC directement qui gère cette option là 
>> (pour les holder particuliers cela dit, aucune idée sur les domaines avec un 
>> holder organisation).. 
>> 
>> J'ai un peu de mal à comprendre comment le paramètre aurait pu sauter à 
>> cause de l'incident de SBG.
>> 
>> Il me semble qu'il y a quelques BDD de whois history dispo sur le net, tu as 
>> essayé de vérifier si le leak coïncide bien avec SBG ?
>> 
>> - Charley
>> 
>> 
>> 
>> Le ven. 12 mars 2021 à 14:49, Philippe ASTIER > <mailto:phili...@astier-consulting.fr>> a écrit :
>> Sur les .fr.
>> 
>> J’ai des .com, .eu, .org, .tech, et tout à l’air OK.
>> 
>>> Le 12 mars 2021 à 14:47, Charley SEDEAU >> <mailto:char...@sedeau.com>> a écrit :
>>> 
>>> Hello,
>>> 
>>> Rien de tel de mon côté sur quelques domaines testés (.fr)
>>> 
>>> Tu vois ça sur quel(s) TLD ?
>>> 
>>> - Charley
>>> 
>>> 
>>> Le ven. 12 mars 2021 à 14:45, Philippe ASTIER via frnog >> <mailto:frnog@frnog.org>> a écrit :
>>> Salut à tous,
>>> 
>>> J’ai plusieurs domaines hébergés chez OVH (mais pas tous) qui se sont mis à 
>>> révéler mes coordonnées : adresse physique, numéro de téléphone, etc… bien 
>>> que le masquage soit toujours bien actif sur la console client.
>>> 
>>> Ca a l’air concomitant avec l’incident de SBG.
>>> 
>>> Vous voyez la même chose ?
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/ <http://www.frnog.org/>
>> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] OVH WHOIS information leak ?

[Philippe ASTIER via frnog]

Je vais regarder, je trouve ça aussi étrange.

Disons qu’on me le fait remonter le lendemain. C’était peut-être là avant, ou 
pas. Mais je ne suis pas le seul, j’ai des exemples en dehors de mes domaines.

Merci à tous ceux qui regardent en tout cas.

J’ai un ticket chez OVH en cours sur le sujet, mais ils sont manifestement sous 
l’eau, et on comprend bien...

> Le 12 mars 2021 à 14:54, Charley SEDEAU  a écrit :
> 
> Bizarre, sur les .fr c'est l'AFNIC directement qui gère cette option là (pour 
> les holder particuliers cela dit, aucune idée sur les domaines avec un holder 
> organisation).. 
> 
> J'ai un peu de mal à comprendre comment le paramètre aurait pu sauter à cause 
> de l'incident de SBG.
> 
> Il me semble qu'il y a quelques BDD de whois history dispo sur le net, tu as 
> essayé de vérifier si le leak coïncide bien avec SBG ?
> 
> - Charley
> 
> 
> 
> Le ven. 12 mars 2021 à 14:49, Philippe ASTIER  <mailto:phili...@astier-consulting.fr>> a écrit :
> Sur les .fr.
> 
> J’ai des .com, .eu, .org, .tech, et tout à l’air OK.
> 
>> Le 12 mars 2021 à 14:47, Charley SEDEAU > <mailto:char...@sedeau.com>> a écrit :
>> 
>> Hello,
>> 
>> Rien de tel de mon côté sur quelques domaines testés (.fr)
>> 
>> Tu vois ça sur quel(s) TLD ?
>> 
>> - Charley
>> 
>> 
>> Le ven. 12 mars 2021 à 14:45, Philippe ASTIER via frnog > <mailto:frnog@frnog.org>> a écrit :
>> Salut à tous,
>> 
>> J’ai plusieurs domaines hébergés chez OVH (mais pas tous) qui se sont mis à 
>> révéler mes coordonnées : adresse physique, numéro de téléphone, etc… bien 
>> que le masquage soit toujours bien actif sur la console client.
>> 
>> Ca a l’air concomitant avec l’incident de SBG.
>> 
>> Vous voyez la même chose ?
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/ <http://www.frnog.org/>
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] OVH WHOIS information leak ?

[Philippe ASTIER via frnog]

Sur les .fr.

J’ai des .com, .eu, .org, .tech, et tout à l’air OK.

> Le 12 mars 2021 à 14:47, Charley SEDEAU  a écrit :
> 
> Hello,
> 
> Rien de tel de mon côté sur quelques domaines testés (.fr)
> 
> Tu vois ça sur quel(s) TLD ?
> 
> - Charley
> 
> 
> Le ven. 12 mars 2021 à 14:45, Philippe ASTIER via frnog  <mailto:frnog@frnog.org>> a écrit :
> Salut à tous,
> 
> J’ai plusieurs domaines hébergés chez OVH (mais pas tous) qui se sont mis à 
> révéler mes coordonnées : adresse physique, numéro de téléphone, etc… bien 
> que le masquage soit toujours bien actif sur la console client.
> 
> Ca a l’air concomitant avec l’incident de SBG.
> 
> Vous voyez la même chose ?
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ <http://www.frnog.org/>


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] OVH WHOIS information leak ?

[Philippe ASTIER via frnog]

Salut à tous,

J’ai plusieurs domaines hébergés chez OVH (mais pas tous) qui se sont mis à 
révéler mes coordonnées : adresse physique, numéro de téléphone, etc… bien que 
le masquage soit toujours bien actif sur la console client.

Ca a l’air concomitant avec l’incident de SBG.

Vous voyez la même chose ?

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

Oui, +1000.

Je suis assez énervé par les trolls qui comprennent pas et n’ont pas compris 
l’ampleur de la catastrophe. Tout ça parce qu’ils ne se sont jamais préoccupés 
eux-même de savoir où étaient leurs backups, ce qui est la règle numéro un en 
informatique depuis toujours, Cloud ou pas cloud.

On aurait pu aussi avoir un dégât sur tremblement de terre d’ailleurs, on en a 
eu trois-quatre dans les derniers mois, et l’épicentre est à moins de 3 km du 
DC d’OVH. 

Ils suggèrent un incendie sur onduleur entretenu le matin maintenant il 
semblerait ?

(Big up aussi aux pompiers allemands qui sont aussi intervenus d’ailleurs, le 
bateau pompe est franco-allemand.)

> Le 11 mars 2021 à 17:43, Stéphane Rivière  > a écrit :
> 
>> La situation est quand même remarquablement bien gérée par OVH ; je ne
>> comprends pas ceux qui se permettent de critiquer.
> 
> +1000
> 
> Et c'est là qu'une usine à serveur en plein propriété, capable de sortir
> plus de 100K serveurs/an prend tout son sens. L'investissement OVH est
> toujours dans l'utile.
> 
> Je dirais que c'est quand même un moindre mal. Pas de corporel (le ou
> les gars sur place, ça a du leur faire très bizarre), SBG3 aurait *du y
> passer* (big up aux pompiers du sdis67) et ils ont même sauvé les 2/3 de
> sgb1.
> 
> J'imagine même pas la température à 20 ou 30 m (ils n'avaient pas
> beaucoup de recul dans la largeur).
> 
> Respect à tous.
> 
> -- 
> Be Seeing You
> Number Six
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

Il y a des rumeurs de l’explosion d’un transformateur 20 kV, qui aurait pu au 
passage endommager le système anti-incendie. Si c’est le cas, ça pourrait 
expliquer la brutalité du départ de leur et le rendre totalement incontrollable.

En tout cas, lors de la coupure de 2017, on avait appris que les 
transformateurs étaient dans les locaux il me semble. A vérifier.


Je pense qu’il vaut mieux laisser l’enquête avancer, on finira par savoir.

Au fait, on en sait plus sur le « bug » qui avait touché RBX le même jour en 
2017 ? L’arrêt simultané de 40 transceivers 100 Gb/s ? Je trouve que ça 
toujours été un mystère cette histoire.

> Le 11 mars 2021 à 13:16, Jerome Lien  a écrit :
> 
> si cela est vraie, je comprends ou il rogne pour avoir des tarifs agressif
> ...
> 
> je cite l'article : "Au-delà de ces questions, une certitude demeure : Les
> centres de données d'OVHCloud à Strasbourg ne sont pas dotés de
> réseaux d'extinction. Ils ne sont pas équipés de gicleurs d'eau comme c'est
> le cas dans les datacenters d'OVHCloud à Beauharnois au Canada, ni
> de brumisateurs haute pression permettant de résorber les flammes tout en
> protégeant les machines contre l'eau, ni de gaz inerte, à l'instart de la
> plupart des datacenters du marché."
> 
> https://www.journaldunet.com/web-tech/cloud/1498567-incendie-chez-ovh-3-6-millions-de-sites-web-sont-tombes/?fbclid=IwAR3nGCLb4XOKVmeLW0J4DNhNA7NcIO7PB5MnQU7jd2ro_QwE81TLNLOFCsg
> 
> Le jeu. 11 mars 2021 à 01:11, Jeremy  a écrit :
> 
>> Salut vouloir faire du sensationnalisme, la vidéo prise par le drone des
>> pompiers cette nuit est particulièrement impressionnante.
>> 
>> On comprend mieux pourquoi le SBG2 est détruit.
>> https://www.youtube.com/watch?v=Mwh4OB_Sb_c
>> 
>> Courage à ceux qui vont revoir retrouver leurs petits dans ce tas de
>> cendre.
>> 
>> Jérémy
>> 
>> 
>> Le 10/03/2021 à 05:16, Johann a écrit :
>>> Hello,
>>> 
>>> Je pense que d'ici le réveil de nombreux d'entre vous, l'information aura
>>> circulé.
>>> Un incendie c'est déclaré cette nuit dans le DC SBG-2 de OVH.
>>> Les pompiers sont sur place mais n'arrive pas à contenir l'incendie pour
>>> l'instant.
>>> L'alimentation électrique a été coupé par sécurité sur l'ensemble des DC
>> de
>>> OVH sur place.
>>> Pas d'ETA et il n'y aura pas d'ETA d'après un mail d'octave sur les ML.
>>> OVH recommande d'activé des maintenant les DRP/Plan de reprise
>> d'activité.
>>> 
>>> https://twitter.com/olesovhcom/status/1369478732247932929
>>> http://travaux.ovh.com/?do=details=49484
>>> 
>>> Bon courage aux pompiers sur place, à toute la team OVH sur le pont et
>> aux
>>> nombreux sysadmin que cela touche.
>>> 
>>> A parier que beaucoup de gens non touchés vont vérifier leur backup et
>> leur
>>> procédure de PRA/PCA demain.
>>> 
>>> Johann
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Re: OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

Far too early to assess.

DC is in crisis mode, so we won’t have further explanation for now.

> Le 10 mars 2021 à 14:53, Rod Beck  a écrit :
> 
> Anyone want to explain why this total disaster? Building materials? Fire 
> suppression systems?
> 
> Feel free to respond in French.
> 
> Regards,
> 
> Roderick.
> 
> 
> From: frnog-requ...@frnog.org  on behalf of 
> Guillaume Tournat via frnog 
> Sent: Wednesday, March 10, 2021 2:38 PM
> To: Fabien Delmotte ; Barthélémy DELUY 
> 
> Cc: frnog-al...@frnog.org 
> Subject: Re: [FRnOG] [ALERT] Re: OVH : SBG-2 en feu
> 
> La partie "Public Cloud" apparait désormais dans le manager.
> 
> Mais il indique "Vous n'avez pas encore créé d’instance."
> 
> J'espère qu'ils n'ont pas perdus toutes les VM...
> 
> 
> Le 10/03/2021 à 11:54, Fabien Delmotte via frnog a écrit :
>> Bonjour,
>> 
>> Effectivement, je suis dans le même cas, impossible d’ouvrir un ticket 
>> auprès du support. Donc le service est bien down et irrécupérable.
>> 
>> Cordialement
>> 
>>> Le 10 mars 2021 à 11:50, Barthélémy DELUY  a écrit :
>>> 
>>> Le plus embêtant, c'est que le manager est partiellement offline lui aussi 
>>> (impossible d'accéder à ses factures, à la gestion des domaines, etc).
>>> 
>>> Donc quand le PRA indique
>>> - "Basculer les IP FO vers le nouveau DC" => la bascule est dans les 
>>> choux
>>>- "changer le CNAME du service vers le site de secours" => on peut pas 
>>> accéder au domaine, c'est gênant...
>>> 
>>> Là, OVH a mal géré son coup...
>>> 
>>> Le mer. 10 mars 2021 à 11:44, Fabien Delmotte via frnog >> > a écrit :
 Je suis à titre perso simple client pour des VPS. L'info de la localisation
 est dans le dashboard d'OVH. Et pour l'instant pas de mail officiel reçu
 d'OVH.
>>> Même remarque j’ai un VPS non joignable et aucune communication. Je me suis 
>>> rendu compte que mon service était « down » et je suis allé chercher 
>>> l’information.
>>> 
>>> Cordialement
>>> 
>>> 
>>> 
 Le 10 mars 2021 à 11:26, Emmanuel Jacquet >>> > a écrit :
 
 Le mer. 10 mars 2021 à 08:52, Clement Cavadore >>> > a
 écrit :
 
> Je n'ai rien à SBG, et ne sais pas si c'est communiqué aux clients,
> mais: Les concernés savent dans quel site ils sont habituellement
> hébergés ? SBG2 étant brûlé, et une partie de SBG1 impacté, ca laisse
> espoir à ceux qui sont hébergés dans les autres salles...
> 
 mailto:m...@formidable-inc.net>>
 Je suis à titre perso simple client pour des VPS. L'info de la localisation
 est dans le dashboard d'OVH. Et pour l'instant pas de mail officiel reçu
 d'OVH.
 Manu
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/ 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/ 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Les STOR-1 sont (étaient) dans quel DC de SBG ?

[Philippe ASTIER via frnog]

Pour SBG1 et SBG2, c’était du Free cooling d’ailleurs. 
Les pompiers ont l’air de dire que ça a poussé un effet de cheminée. Logique, 
si tu évacues bien la chaleur, tu entretiens bien le feu aussi.

Sinon, le SDIS, c’est 67 hein (Bas-Rhin), pas 77 (Seine-et-Marne) ;)

> Le 10 mars 2021 à 13:32, Stéphane Rivière  a écrit :
> 
>> Si j'en crois google maps, la réfrigération est probablement HS pour
>> SBG3 (entre SBG2 et SBG3) - mais ce n'est qu'une hypothèse, fondée sur
> 
> J'ai certainement dit une bêtise (et heureusement) cette photo montre
> que les aéroréfrigérants de SBG3 sont sur le toit de SBG3 et que le
> bâtiment de liaison entre SBG3 et SBG2 appartient à SBG2.
> 
> Donc la remise en service de SBG3, au moins vu de l'extérieur, ne sera
> peut-être pas lié à la centrale frigo.
> 
> https://twitter.com/sdis67/status/1369597903535304705/photo/4
> 
> Merci au sdis 77 pour cette photo aérienne par leur drone.
> 
> Accessoirement, y'a deux cuves fuel à droite (orange pâle) dans leur
> fosse de rétention pour les 3 groupes de droite et un très gros
> réservoir de... (GPL ?) pour les 10 groupes au premier plan...
> 
> -- 
> Be Seeing You
> Number Six
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Re: OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

Le souci c’est qu’on ne connait pas encore l’impact réel, et OVH n’a pas accès 
au site.

En particulier, impossible de savoir si les arrivées réseau sont aussi 
touchées. Auquel cas, bâtiment intact, mais pas relié… ouille.

Des photos ici : 
https://www.dna.fr/faits-divers-justice/2021/03/10/strasbourg-important-incendie-dans-une-entreprise-situee-sur-un-site-seveso-au-port-du-rhin

> Le 10 mars 2021 à 08:50, Clement Cavadore  a écrit :
> 
> C'est sûr, ca fait peur. Bon, du coup, ca donnera des expériences pour
> les prochaines constructions, afin d'éviter la propagation des
> incendies entre les bâtiments...
> 
> Je n'ai rien à SBG, et ne sais pas si c'est communiqué aux clients,
> mais: Les concernés savent dans quel site ils sont habituellement
> hébergés ? SBG2 étant brûlé, et une partie de SBG1 impacté, ca laisse
> espoir à ceux qui sont hébergés dans les autres salles...
> 
> Clément
> 
> Le mercredi 10 mars 2021 à 08:43 +0100, Johann a écrit :
>> Les images font mal au cœur.
>> Peu de chance de récupérer quelques choses...
>> 
>> https://twitter.com/abonin_DNA/status/1369538028243456000?s=19
>> 
>> Le mer. 10 mars 2021 à 08:42, Oliver varenne 
>> a
>> écrit :
>> 
>>> Merci
>>> Heureusement rien de critique sur les VM (d’où la non utilisation
>>> de HA)
>>> On va pouvoir remonter tout ça dans la matinée tranquillement.
>>> 
>>> Mais ça doit être le feu (...) chez OVH en ce moment ☹ j'aimerai
>>> pas être
>>> à leur place!
>>> 
>>> 
>>> 
>>> Cordialement,
>>> 
>>> 
>>> 
>>> Olivier Varenne
>>> Co-gérant, Commercial & Développeur
>>> T +33 (0)4 27 04 40 00 | ipconnect.fr
>>> 
>>> Suivez-nous !
>>> 
>>> 
>>> 
>>> 
 -Message d'origine-
 De : Cyril CALMON - TCT 
 Envoyé : mercredi 10 mars 2021 08:37
 À : Oliver varenne ; 
 frnog-al...@frnog.org
 Cc : Jolan FARROUCH - TCT 
 Objet : RE: [FRnOG] [ALERT] Re: OVH : SBG-2 en feu
 
 Bonjour
 
 Si vous avez des besoins nous avons de la dispo en ressource
 de  VM (
 enfin pour le moment car il a pas mal de demande en cours )
 
 -Message d'origine-
 De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De
 la part
 de Oliver varenne Envoyé : mercredi 10 mars 2021 08:31 À : frnog-
 al...@frnog.org Objet : RE: [FRnOG] [ALERT] Re: OVH : SBG-2 en
 feu
 
 Une vingtaine de VM HS du coup chez nous On va monter les backup
 mais vu que tout le monde fait pareil, c'est un peu compliqué...
 
 
 
 Cordialement,
 
 
 
 Olivier Varenne
 Co-gérant, Commercial & Développeur
 T +33 (0)4 27 04 40 00 | ipconnect.fr
 
 Suivez-nous !
 
 
 
 
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la
> part de
> Johann Envoyé : mercredi 10 mars 2021 05:30 À : 
> frnog-al...@frnog.org
> Objet : [FRnOG] [ALERT] Re: OVH : SBG-2 en feu
> 
> Petite update :
> Le feu à complètement détruit SBG-2 et une partie de SBG-1 :-(
> Les
> pompiers protèges SBG-3 et aucun impact sur SBG-4
> 
> https://twitter.com/olesovhcom/status/1369504527544705025
> 
> Le mer. 10 mars 2021 à 05:16, Johann  a écrit
> :
> 
>> Hello,
>> 
>> Je pense que d'ici le réveil de nombreux d'entre vous,
>> l'information
>> aura circulé.
>> Un incendie c'est déclaré cette nuit dans le DC SBG-2 de OVH.
>> Les pompiers sont sur place mais n'arrive pas à contenir
>> l'incendie
>> pour l'instant.
>> L'alimentation électrique a été coupé par sécurité sur
>> l'ensemble
>> des DC de OVH sur place.
>> Pas d'ETA et il n'y aura pas d'ETA d'après un mail d'octave
>> sur les
>>> ML.
>> OVH recommande d'activé des maintenant les DRP/Plan de
>> reprise
> d'activité.
>> https://twitter.com/olesovhcom/status/1369478732247932929
>> http://travaux.ovh.com/?do=details=49484
>> 
>> Bon courage aux pompiers sur place, à toute la team OVH sur
>> le pont
>> et aux nombreux sysadmin que cela touche.
>> 
>> A parier que beaucoup de gens non touchés vont vérifier leur
>> backup
>> et leur procédure de PRA/PCA demain.
>> 
>> Johann
>> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 Cordialement,
 
 
 [https://tct-telecom.fr/logo/logotct.png]   Mr CALMON Cyril
 Responsable commercial & site
 42 Avenue MONTAIGNE
 75008 Paris
 
 
 Tél standard : 09 70 26 70 00
 Tél direct  : 01 85 01 26 19
 Mobile  : 06 15 98 17 57
 
 
 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de 

Re: [FRnOG] [TECH] Starlink de Elon Musk arrive en France !

[Philippe ASTIER via frnog]

Si tu veux une excellente analyse de l’antenne côté client : 
https://www.youtube.com/watch?v=h6MfM8EFkGg



> Le 9 mars 2021 à 17:59, Nang Bat  a écrit :
> 
> Oui mais pas que, la ressource radio est pas illimité, et donc le downlink
> de starlink c'est 2ghz de Ku, donc un gros paramètre dimensionnant c'est la
> taille mini d'un spot (une cellule) qu'un satellite peu former au sol, qui
> te donne la borne sup du débit par unité de surface. Après il faut avoir
> assez de satellites pour éclairer toute les zones d'autant plus si elles
> sont petites et idéalement avoir une payload qui peut faire du beamforming
> à la demande. Donc un éléments dimensionnant va être la performance de la
> payload et ça bah... on n'en sait pas grand chose (si y'a des info je veux
> bien :D)
> Apres pour ce qui est du routage du traffic, c'est pas trivial mais c'est
> bien maitrisé (cf. Iridium, ça reste du calcul de SPF), le couplage avec
> des beam dynamique et 12 000 satellites complexifie certes le trucs mais ça
> reste dans le domaine du faisable.
> 
> Le mar. 9 mars 2021 à 17:43, Richard Klein  a écrit :
> 
>> 20G c'est pour 1 satellite
>> Starlink utilise une constellation de satellites qui ne sont pas
>> stationnaire par rapport à une station fixe.
>> Il est certain qu'une station au sol ( un utilisateur) captera plusieurs
>> satellites et fera de l'agrégation de bande passante .
>> Lorsque les satellites commenceront à dialoguer entre eux en mode mesh la
>> charge va s'équilibrer. Donc vos calculs sont valables pour un satellite
>> géostationnaire mais par pour une constellation en mouvement au dessus de
>> nos têtes.
>> J'ais tous bon?
>> 
>> Richard
>> 
>> 
>> Le mar. 9 mars 2021 à 16:14, Michel Py >> 
>> a écrit :
>> 
 Kevin LABÉCOT a écrit :
 De mon côté je suis à 27km de la base terrestre de Villenave d'Ornon
>> qui
>>> serait terminée d'après le journal Sud Ouest.
 Je suis inscrit depuis l'ouverture des "inscriptions" en France... Wait
>>> & See
>>> 
>>> Un satellite Starlink c'est environ 20G de bande passante (quand il fait
>>> beau); reste à voir combien de clients ils vont mettre dessus. La France
>>> (surtout le Nord) est bien placée, la meilleure couverture possible est
>> au
>>> alentours du 50ème parallèle donc même aujourd'hui il y a couverture
>>> permanente. Mais 20G pour couvrir l'ensemble du territoire, ça fait pas
>> un
>>> nombre illimité de clients.
>>> 
>>> Michel.
>>> 
>>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Starlink de Elon Musk arrive en France !

[Philippe ASTIER via frnog]

Ca a été à un moment dans le TOS de Starlink (je ne sais pas si ça y est 
encore) :


“For Services provided on Mars, or in transit to Mars via Starship or other 
colonization spacecraft, the parties recognize Mars as a free planet and that 
no Earth-based government has authority or sovereignty over Martian activities. 
Accordingly, Disputes will be settled through self-governing principles, 
established in good faith, at the time of Martian settlement.”


Même si quelqu’un d’autre a une initiative, qui lancera les satellites, et avec 
combien d’années de retard ? Space X lance plus de satellites que n’importe qui 
d’autre...

> Le 9 mars 2021 à 18:03, Richard Klein  <mailto:varicap@gmail.com>> a écrit :
> 
> Petit bonus et que personne ne voit arriver .
> Vous vous souvenez du test de Boeing et de sa capsule starliner et de son 
> gros raté.
> Un des problèmes était que le starliner n'était pas joignable pour le 
> reprogrammer.
> Cela veux dire qu'une boîte comme Boeing n'avait pas une couverture radio 
> intégrale au lancement et tracking du starliner .
> 
> Starlink pourrait êtres une réponse...
> 
> Question il se passera quoi quand les équipes de starlink vont équiper la 
> petite flotte de satellites avec des antennes qui ne seront plus dirigé vers 
> la terre mais vers l'espace?
> Il y aura donc une couverture a 360degres et 3D vers la lune et vers Mars
> Et rien n'empêche starlink de lancer une dizaine de satellites plus haut en 
> géostationnaire pour sur-alimenter les satellites en "base altitude".
> 
> Bref l'actu va bouger  et ce n'est pas la France qui va bloquer ce type de 
> projet 
> 
> Richard
> 
> Le mar. 9 mars 2021 à 17:45, Philippe ASTIER via frnog  <mailto:frnog@frnog.org>> a écrit :
> Euh, en fait, le calcul n’est pas bon, parce que trop simpliste.
> 
> Ne pas oublier que Starlink est en orbite basse à défilement, pas en orbite 
> géostationnaire !
> 
> Une antenne est connectée à plusieurs satellites, et les satellites à 
> plusieurs stations de base et plusieurs satellites aussi à terme. Le calcul 
> de la bande passante totale disponible est de fait beaucoup plus complexe.
> 
> Après ça veut aussi dire que l’établissement du circuit pour faire passer le 
> trafic n’est vraiment pas trivial du tout. Il n’est pas du tout évident que 
> l’on sorte par le point territorialement le plus proche. 
> 
> L’intérêt d’ailleurs des liens intersatellites, c’est de passer par son 
> propre backbone, et pas par des réseaux terrestres.
> 
> Il y a un site qui décrit les flux envisagés. L’idée est qu’un chemin par 
> plusieurs satellites peut-même être plus court que par des fibres terrestres. 
> https://hackaday.com/2020/02/20/how-does-starlink-work-anyway/ 
> <https://hackaday.com/2020/02/20/how-does-starlink-work-anyway/>
> 
> 
> > Le 9 mars 2021 à 16:22, Emmanuel DECAEN  > <mailto:emmanuel.dec...@xsalto.com>> a écrit :
> > 
> > 
> > Le 09/03/2021 à 16:14, Michel Py via frnog a écrit :
> >>> Kevin LABÉCOT a écrit :
> >>> De mon côté je suis à 27km de la base terrestre de Villenave d'Ornon qui 
> >>> serait terminée d'après le journal Sud Ouest.
> >>> Je suis inscrit depuis l'ouverture des "inscriptions" en France... Wait & 
> >>> See
> >> Un satellite Starlink c'est environ 20G de bande passante (quand il fait 
> >> beau); reste à voir combien de clients ils vont mettre dessus. La France 
> >> (surtout le Nord) est bien placée, la meilleure couverture possible est au 
> >> alentours du 50ème parallèle donc même aujourd'hui il y a couverture 
> >> permanente. Mais 20G pour couvrir l'ensemble du territoire, ça fait pas un 
> >> nombre illimité de clients.
> > 
> > 
> > Si on parle de 20 Gbps, ça fait environ 6 666 clients Netflix...
> > 
> > Pour le calcul à l'arrache:
> >  -> environ 3 Mbps par client : 
> > https://ispspeedindex.netflix.net/country/france/ 
> > <https://ispspeedindex.netflix.net/country/france/>
> >  -> 20 000 / 3  = 6 666
> > 
> > La fibre et l'ADSL ont un bel avenir ;-)
> > 
> > -- 
> > *Emmanuel DECAEN*
> > 
> > 
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/ <http://www.frnog.org/>
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ <http://www.frnog.org/>


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Starlink de Elon Musk arrive en France !

[Philippe ASTIER via frnog]

Bah oui. +1000 tout pile poil ce que je viens d’écrire. 

> Le 9 mars 2021 à 17:42, Richard Klein  a écrit :
> 
> 20G c'est pour 1 satellite
> Starlink utilise une constellation de satellites qui ne sont pas stationnaire 
> par rapport à une station fixe.
> Il est certain qu'une station au sol ( un utilisateur) captera plusieurs 
> satellites et fera de l'agrégation de bande passante .
> Lorsque les satellites commenceront à dialoguer entre eux en mode mesh la 
> charge va s'équilibrer. Donc vos calculs sont valables pour un satellite 
> géostationnaire mais par pour une constellation en mouvement au dessus de nos 
> têtes.
> J'ais tous bon?
> 
> Richard
> 
> 
> Le mar. 9 mars 2021 à 16:14, Michel Py  > a écrit :
> > Kevin LABÉCOT a écrit :
> > De mon côté je suis à 27km de la base terrestre de Villenave d'Ornon qui 
> > serait terminée d'après le journal Sud Ouest.
> > Je suis inscrit depuis l'ouverture des "inscriptions" en France... Wait & 
> > See
> 
> Un satellite Starlink c'est environ 20G de bande passante (quand il fait 
> beau); reste à voir combien de clients ils vont mettre dessus. La France 
> (surtout le Nord) est bien placée, la meilleure couverture possible est au 
> alentours du 50ème parallèle donc même aujourd'hui il y a couverture 
> permanente. Mais 20G pour couvrir l'ensemble du territoire, ça fait pas un 
> nombre illimité de clients.
> 
> Michel.
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Starlink de Elon Musk arrive en France !

[Philippe ASTIER via frnog]

Euh, en fait, le calcul n’est pas bon, parce que trop simpliste.

Ne pas oublier que Starlink est en orbite basse à défilement, pas en orbite 
géostationnaire !

Une antenne est connectée à plusieurs satellites, et les satellites à plusieurs 
stations de base et plusieurs satellites aussi à terme. Le calcul de la bande 
passante totale disponible est de fait beaucoup plus complexe.

Après ça veut aussi dire que l’établissement du circuit pour faire passer le 
trafic n’est vraiment pas trivial du tout. Il n’est pas du tout évident que 
l’on sorte par le point territorialement le plus proche. 

L’intérêt d’ailleurs des liens intersatellites, c’est de passer par son propre 
backbone, et pas par des réseaux terrestres.

Il y a un site qui décrit les flux envisagés. L’idée est qu’un chemin par 
plusieurs satellites peut-même être plus court que par des fibres terrestres. 
https://hackaday.com/2020/02/20/how-does-starlink-work-anyway/


> Le 9 mars 2021 à 16:22, Emmanuel DECAEN  a écrit :
> 
> 
> Le 09/03/2021 à 16:14, Michel Py via frnog a écrit :
>>> Kevin LABÉCOT a écrit :
>>> De mon côté je suis à 27km de la base terrestre de Villenave d'Ornon qui 
>>> serait terminée d'après le journal Sud Ouest.
>>> Je suis inscrit depuis l'ouverture des "inscriptions" en France... Wait & 
>>> See
>> Un satellite Starlink c'est environ 20G de bande passante (quand il fait 
>> beau); reste à voir combien de clients ils vont mettre dessus. La France 
>> (surtout le Nord) est bien placée, la meilleure couverture possible est au 
>> alentours du 50ème parallèle donc même aujourd'hui il y a couverture 
>> permanente. Mais 20G pour couvrir l'ensemble du territoire, ça fait pas un 
>> nombre illimité de clients.
> 
> 
> Si on parle de 20 Gbps, ça fait environ 6 666 clients Netflix...
> 
> Pour le calcul à l'arrache:
>  -> environ 3 Mbps par client : 
> https://ispspeedindex.netflix.net/country/france/
>  -> 20 000 / 3  = 6 666
> 
> La fibre et l'ADSL ont un bel avenir ;-)
> 
> -- 
> *Emmanuel DECAEN*
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Starlink de Elon Musk arrive en France !

[Philippe ASTIER via frnog]

Aujourd’hui, en beta, ils ont en gros 100-120 Mb/s en download, 30-60 en 
upload, et une latence assez faible (25-35 ms), parce que c’est des orbites 
basses, c’est assez malin.

Ils ont promis 1 Gb/s d’ici la fin de l’année, avec des plans pour monte à 10 
Gb/s, mais bon, promesse marketing…

Les liens lasers entre satellites sont prévus mais pas encore fonctionnels. 
Techniquement, ça doit être assez marrant de pointer vers ses voisins qui 
bougent…

On parle de $500 pour l’installation, et $100/mois. Très très raisonnable vu 
que ça ira partout ou le cuivre ou la fibre n’iront probablement jamais.

> Le 23 févr. 2021 à 16:41, Michel Merle  a écrit :
> 
> Raisonnement par l’absurde, c’est sans doute plus compliqué que cela, mais : 
> La partie émergée de la terre représente 128 Millions de km2, ce qui avec 42 
> 000 sats à terme fait un footprint de 3500 km2 par sat.
> 
> Reste à savoir quelle sera la BP allouée à chaque empreinte, la taille de 
> l’uplink local (il y en aura plusieurs par continent / pays), et la qualité 
> des interco (je crois de mémoire avoir lu en laser) entre les sats.
> 
> Et ca, c’est avant même de considérer le prix, of course.
> 
> mM
> 
>> On 23 Feb 2021, at 16:28, Hugo SIMANCAS >  
>> > >> wrote:
>> 
>> on en parle ? :)
>> 
>> https://www.rtbf.be/info/monde/detail_projet-starlink-d-elon-musk-3-des-satellites-seraient-deja-en-panne?id=10612811
>>  
>> 
>>  
>> >  
>> >
>> 
>> 3% de 42000 ça en fait quand même
>> 
>> 
>> 
>> / ::1  Hugo SIMANCAS
>> Directeur Technique Associé
>> https://www.data-expertise.com [https://www.data-expertise.com/]
>> Support technique : 09 78 23 20 29
>> Standard : 05 34 26 02 46 | Ligne directe : 05 34 26 50 57
>> Mobile : 06 95 44 29 64
>> !Utilisez notre plateforme visio libre & gratuite : 
>> https://conf.data-expertise.com/ [https://conf.data-expertise.com/]
>> !Pad collaboratif libre & gratuit sécurisé https://pad.data-expertise.com/ 
>> [https://pad.data-expertise.com/]
>> 
>> Les informations contenues dans ce courrier électronique sont 
>> confidentielles et protégées par le secret professionnel. En tout état de 
>> cause, elles ne sont destinées qu'à la personne ou entreprise dont le nom 
>> est mentionné ci-dessus. Veuillez aviser l'expéditeur de toute difficulté ou 
>> de toute erreur dans la transmission de ce document. Si vous n'êtes pas le 
>> destinataire du présent courrier, vous n'êtes pas autorisé, sous peine de 
>> poursuites à en prendre des copies, le divulguer ou le diffuser. La présence 
>> de cette note prouve également que ce message électronique a été vérifié par 
>> un logiciel anti-virus.
>> 
>> 
>> 
>> Le 23/02/2021 à 15:01, Jugurta YENNEK a écrit :
>>> L'Arcep a autorisé Starlink à utiliser certaines fréquences qui vont lui
>>> permettre d'apporter du très haut débit par satellite dans les zones
>>> reculées de France …
>>> 
>>> 
>>> 
>>> Une alternative a la fibre et la 4/5G dans les zones blanche ?
>>> 
>>> 
>>> 
>>> https://antiphishing.vadesecure.com/2/aHVnby5zaW1hbmNhc0BkYXRhLWV4cGVydGlzZS5jb218VlJDNDc0NjUz/www.lesechos.fr/tech-medias/hightech/internet-par-satellite-starlink
>>> -le-projet-delon-musk-debarque-en-france-1292036
>>> 
>>> 
>>> 
>>> ---
>>> 
>>> Jugurta
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> https://antiphishing.vadesecure.com/1/aHVnby5zaW1hbmNhc0BkYXRhLWV4cGVydGlzZS5jb218VlJDNDc0NjUz/www.frnog.org/
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ 

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent

[Philippe ASTIER via frnog]

Alors oui...

IPv6 est obligatoire pour tous les devices Apple HomeKit, sinon ils ne sont pas 
certifiés.
La plateforme commune CHIP (Apple, Amazon, Google, ZigBee) est sensée ne 
fonctionner qu’en IPv6 (mais on n’a encore rien vu).

Thread est basé sur IPv6 / 6LoWPAN (très succinct sur Wikipedia : 
https://en.wikipedia.org/wiki/Thread_(network_protocol)) 
.

J’ai pas dit qu’on avait ça dans les devices IoT no-name à 30€….

Je viens de vérifier chez moi : pont Philips Hue, passerelle Ikea Tradfri, 
ponts Eve, etc… tous font de l’IPv6. Bon, mon Frigo et les clims ne parlent 
encore que v4.

> Le 9 févr. 2021 à 13:06, Xavier Beaudouin  a écrit :
> 
> Hello,
> 
>> IPv6, ça laisse ton IOT v6 à poil quand Free "oublie" le pare-feu, et (sans 
>> NAT)
>> ça ne fait rien pour le PI du pauvre.
> 
> Heu... T'as vu bcp de choses IOT en IPv6 ? Moi rien... Et même quand j'essaye 
> d'en faire avec des ESP12-F / ESP32, la dual stack v6 est quasi inexistante.
> Alors le bidule IOT chez X ou Y vendu dans une belle boite avec option je te 
> tiens par les couilles dans un n-ieme cloud, clairement ils ont pas activé 
> l'option sur leur IDE Arduino
> 
> /Xavier
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] SG250-08HP - Retour d'une expérience cauchemardesque.

[Philippe ASTIER via frnog]

Ouais, ça sent le problème électrique à plein nez, je peux pas croire que 8 
switchs simultanément soient en panne au déballage, c’est énorme.


> Le 9 févr. 2021 à 10:05, Nicolas Parpandet  a écrit :
> 
> 
> Problème de POE ?,
> d'alim ?
> 
> Nicolas
> 
> 
> - Mail original -
>> De: "Guillaume Robier" 
>> À: "frnog-misc" 
>> Envoyé: Mardi 9 Février 2021 09:45:06
>> Objet: [FRnOG] [MISC] SG250-08HP - Retour d'une expérience cauchemardesque.
> 
>> Bonjour la liste,
>> 
>> 
>> 
>> Est-ce que certains d’entre vous utilise les Cisco SG250-08HP ?
>> 
>> 8 d’entre eux mon claqué dans les doigts. Ils ne démarrent que lorsque
>> qu’ils ne sont connecté à rien. Sympa pour un switch !
>> 
>> 
>> 
>> Cordialement,
>> 
>> 
>> 
>> Guillaume Robier.
>> 
>> g...@robier.org 
>> 
>> 
>> 
>> 
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent

[Philippe ASTIER via frnog]

Il y a aussi les Jumbo Frames, option payante à plusieurs milliers de dollars 
sur les serveurs SunOS à une époque… Et par carte d’interface s’il vous plait.
Soi disant un driver différent, cette bonne blague !

Sur HP-UX en même temps, c’était gratuit mais fallait quand même appliquer un 
patch.

> Le 27 janv. 2021 à 10:53, David Ponzone  a écrit :
> 
>> Le 27 janv. 2021 à 10:32, Jean-Yves LENHOF  a écrit 
>> :
>> 
>> 
>> 
>> Il y a pire, la gamme Power d'IBM... Il te faut une clé d'activation pour 
>> déverrouiller des processeurs déjà présents dans le serveur que tu achètes ! 
>> Ca s'appelle du CuOD ! Sont fort les marketeux !
>> 
> 
> Ca se fait aussi dans l’automobile depuis pas mal de temps je crois, et je 
> crois que cela correspond à une réalité industrielle.
> Après, il y a toujours des gens qui veulent avoir tout pour pas cher, sans 
> comprendre (enfin, sans vouloir admettre plutôt) qu’ils ont accès à la 
> version pas chère parce qu’il y a un autre mec qui achète la version chère.
> Ca serait plus probablement plus compliqué de voyager en avion pour 300€ s’il 
> n'y avait pas des gens qui paient leur billet entre 3000€ et 5000€.
> Pourtant, à quelques détails anecdotiques près, c’est le même voyage.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] 1.1.1.1 sur France-IX

[Philippe ASTIER via frnog]

Yep ! Réactifs, CloudFlare :)

philippe@Mini-M1 Application Support % host yahoo.fr 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:

yahoo.fr has address 74.6.136.150
yahoo.fr has address 124.108.115.100
yahoo.fr has address 212.82.100.150
yahoo.fr has address 106.10.248.150
yahoo.fr has address 98.136.103.23
yahoo.fr mail is handled by 10 mx-eu.mail.am0.yahoodns.net.

> Le 13 janv. 2021 à 18:24, Clement Cavadore  a écrit :
> 
> Probleme réglé :)
> 
> HostLoss%   Snt   Last   Avg  Best  Wrst StDev
> (...)
> 2. hundredgige0-8-0-2.auvtr5.auberv  0.0% 20.9   0.9   0.9   0.9   0.0
> 3. hundredgige0-1-0-10.partr2.saint  0.0% 20.9   0.9   0.9   0.9   0.0
> 4. cloudflare-18.gw.opentransit.net  0.0% 21.8   1.6   1.4   1.8   0.2
> 5. one.one.one.one   0.0% 11.2   1.2   1.2   1.2   0.0
> 
> Le mercredi 13 janvier 2021 à 09:06 -0800, Louis Poinsignon a écrit :
>> On a mis à jour Cloudflare status: pour suivre l'incident en cours
>> https://www.cloudflarestatus.com/incidents/t2vcfxt28rwn
>> 
>> On Wed, Jan 13, 2021 at 8:54 AM Jérôme Fleury 
>> wrote:
>> 
>>> Merci pour le signalement. C'est en cours d'investigation chez
>>> Cloudflare.
>>> 
>>> En ce qui concerne l'annonce sur les RS, je confirme que Cloudflare
>>> n'annonce pas 1.1.1.0/24 et 1.0.0.0/24 sur les route-servers de
>>> FranceIX
>>> (et aucun route-server en general)
>>> 
>>> On Wed, Jan 13, 2021 at 5:48 PM Clement Cavadore <
>>> clem...@cavadore.net>
>>> wrote:
>>> 
 Message passé à qui de droit pour 1.1.1.1, tant coté Cloudflare,
 que
 OTI. (Nb: 1.0.0.1 fonctionne depuis OTI)
 
 Le mercredi 13 janvier 2021 à 17:30 +0100, Romain a écrit :
> Si, ça dépend comment tu tests. Ca a été corrigé via le
> firmware il y
> a
> longtemps, même si un traceroute par défaut le route en local
> sur la
> livebox.
> Un traceroute en UDP sur le port 53 montre bien un routage
> correct
> vers
> l'extérieur.
> 
> Le mer. 13 janv. 2021 à 17:17, Paul Caranton <
> caranton.p...@gmail.com
>> a
> écrit :
> 
>> 1.1.1.1 ne fonctionne pas derrière une Livebox (pas la 4 en
>> tout
>> cas).
>> 
>> Paul
>> AS208261
>> 
>> Le 13 janv. 2021 à 17:16, à 17:16, Raphael Mazelier <
>> r...@futomaki.net> a
>> écrit:
>>> Je ne sais pas mais chez moi (cnx orange) 1.1.1.1 était
>>> pétave
>>> aussi.
>>> 
>>> On 13/01/2021 17:03, David Ponzone wrote:
 Ami.e.s France-IXien.ne.s,
 
 Est-ce normal que Cloudflare n’annonce pas le 1.1.1.0/24
 aux RS
 de
>>> France-IX ?
 Merci
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/



signature.asc
Description: Message signed with OpenPGP

Re: [FRnOG] [TECH] 1.1.1.1 sur France-IX

[Philippe ASTIER via frnog]

Bon je confirme, 1.1.1.1 par terre, 1.0.0.1 fonctionnel sur une fibre Orange. 
(LB4)

Le problème n’est pas la Livebox, j’utilise CloudFlare régulièrement sans souci 
depuis longtemps.

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Pourquoi les entreprises désactivent IPv6

[Philippe ASTIER via frnog]

>> Erwan David a écrit :
>> Moi j'aurais dit "disable windows", non ?
> 
> Cà fait 30 ans que tout le monde essaie. Même problème : c'est de la merde, 
> mais écrire qu'il faut s'en débarrasser c'est perdre son temps.
> Tu veux te débarrasser de Micro$hiotte Windoze ? 3 milliards d'humains (ou 
> plus) te soutiennent. Pourquoi depuis 30 ans toi et les milliers de vieux 
> cons qui étaient jeunes cons en leur temps ont échoué : parce que vous n'avez 
> toujours pas compris comment marche le business. J'ai été un jeune con ;-)


Je suis pas d’accord du tout. Je croise tous les jours des boites qui ont juste 
totalement viré Windows (ou au moins on-prem), voire MS totalement. Et puis 
même, c’est pas parce qu’on a du Windows qu’on les configure n’importe comment, 
qu’on accepte de vieilles authentifications, ou qu’on ne gère pas le reste de 
l’infra.

Maintenant, ya toujours des gens qui préfèrent payer des auditeurs pour faire 
des recommandations qui ont 20 ans d’âge plutôt que de se retrousser les 
manches et de s’attaquer aux vrais problèmes.

On est au temps des IdP en SAML et de protocoles pour lesquels les bugs d’IPv4 
ou v6 ne vont rien changer, parce qu’on se repose sur des certificats (et ça 
pose d’autres soucis).

Bref, j’insiste, mais en 2021, faut juste considérer que son LAN est aussi 
dangereux que le WAN, même si on prends plus de précautions. C’est les postes 
qu’il faut protéger individuellement et la communication vers les services de 
l’entreprise. On fait d’une pierre deux coups, parce qu’on règle en même temps 
la sécurité à l’extérieur de l’entreprise, y compris en télétravail.

Mais pas de souci. On peut faire de l’IPv4 seulement, du binding sur des 
contrôleurs de domaine on-prem. On peut même encore utiliser une machine à 
écrire en fait.

Le souci remonté ici, c’est pas IPv6; c’est purement Windows, qu’on corrige en 
coupant IPv6.
Autant tirer le câble réseau, c’est plus secure.

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Pourquoi les entreprises désactivent IPv6

[Philippe ASTIER via frnog]

Je plusoie.

OK, IPv6 a facilité l’accès à une merde de Windows, sur une infra boiteuse où 
IPv6 n’est pas maitrisé, les serveurs mais configurés. 
On peut aussi faire du rogue DHCPv4 et intercepter le traffic des clients si 
l’infra est merdique.

A ce tarif là, IPv4 transporte des virus tous les jours, let’s ban IPv4.

Sérieusement, le problème n*1, maintenant que Flash est décédé, ça reste 
Windows. 
Faire transiter des mots de passe hashés, ça devrait même pas exister.

C’est pas pour rien que les entreprises modernes font du réseau « zéro-trust » 
même en interne. 
Donc oui, 802.1x, certificats, etc… et du coup, les faiblesses d’IPv4 ou v6, on 
s’en fout.

Faut considérer que son LAN est aussi insecure que du WAN dans un lieu public 
et adapter son infrastructure en conséquence.

> Le 6 janv. 2021 à 08:05, Erwan David  > a écrit :
> 
> Le 06/01/2021 à 05:57, Michel Py a écrit :
> 
>>> Key Recommendations :
>>> - Susceptible to Rogue IPv6 DHCP Server Attack: Disable IPv6 on internal 
>>> Windows hosts if not in use.
>> C.Q.F.D.
>> Comme je le dis depuis des années : IPv6 : 2 fois le travail, et 3 fois les 
>> emmerdes.
>> ipv6 route ::/0 null0 c'était déjà là, je vais réfléchir à quelques préfixes 
>> plus longs.
>> Et qui c'est qui va se palucher les scripts Powershell pour désactiver IPv6 
>> ? ben devinez, c'est bibi, ou l'autre barbu.
>> Est-ce que je suis payé pour le faire ? Oui, et pas trop mal. Est-ce que 
>> j'ai quelque chose de mieux à foutre : oui, aussi.
>> Le troll "yàkà faire du IPv6 only", il meurt de faim depuis 15 ans. C'est 
>> pour dreudi, en [MISC].
>> Michel.
>> (1) Guy Lux, sur RMC si je me rappelle bien.
> Moi j'aurais dit "disable windows", non ?
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ 


---
Liste de diffusion du FRnOG
http://www.frnog.org/