Re: [FRnOG] [TECH] Wireguard et DPD ?

[Julien Escario]

Le 11/03/2024 à 09:32, Toussaint OTTAVI a écrit :

Salut la liste,


Bonjour,

Des sites distants montent des VPN Wireguard vers un hub central, défini 
par un FQDN. L'adresse IP du hub change. L'enregistrement DNS 
correspondant est mis à jour. Mais sur les sites distants, Wireguard 
reste "accroché" à l'ancienne IP, il ne fait jamais de nouvelle 
résolution DNS, il ne s'aperçoit pas que son remote ne répond plus, et 
ne re-négocie jamais son tunnel. La seule solution est de redémarrer 
Wireguard  (pour peu que l'on ait encore accès au site).


Wireguard ne retente pas de résolution DNS tant que le tunnel est monté. 
Je me souviens m'être heurté à cette limitation dans une vie antérieure.
J'avais lu qu'au démarrage du tunnel, WG fait sa résolution et ouvre le 
socket de connexion vers l'adresse IP elle-même.


En fouillant dans la doc de Wireguard, je ne trouve pas de fonction 
"Dead Peer Detection", qui aurait permis de réinitialiser un tunnel qui 
ne répond plus. Certes, le DPD en général n'a jamais été une science 
exacte :-) Mais dans Wireguard, apparemment, c'est déterministe : il n'y 
en a pas  :-)


WG a vraiment une volonté de rester hyper centré sur le montage du 
tunnel. Mon avis étant que c'était pour pouvoir être intégré rapidement 
dans le kernel (ce qui a bien boosté son adoption d'ailleurs).


La solution trouvée à l'époque était de monitorer + restart du tunnel en 
cas d'indispo du peer (*). Jamais trouvé de mécanisme interne.

Peut être que des solutions packagées sont apparues des 2 dernières années.

Julien

* : trop tôt pour les trolls mais pour le coup, ca se fait bien avec 
systemd ;-)



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

Re: [FRnOG] [TECH] Les cabinets comptables & la cyber

[Julien Escario]

Bonjour,
Pardon de mettre mon grain de sel mais je crois comprendre le fond du 
problème : les CAC appliquent la même logique de risque matériel 
raisonnable au systèmes d'informations.


Hors, on peut considérer que dans le cas d'une machine métier ou d'un 
bâtiment, un risque de casse ou d’incendie va se traduire par un arrêt 
de prod plus ou moins long et donc une provision pour couvrir ce risque.


Dans le cas d'une brèche dans le S.I. d'une boite, c'est juste ... mort. 
Si un vilain est rentré, il a copié toutes les données, chiffré 
l'ensemble et/ou pété les sauvegardes, il n'y aura pas de reprise 
d'activité.


En gros, c'est comme si on provisionnait 100% de la valorisation de la 
boite, ca n'a aucun sens.


Alors oui, les données ca se reconstruit mais dans les exemples que j'ai 
pu observer, la boite ne s'en remet jamais.


Donc en fait, c'est tout ou rien : soit le S.I. est inviolable (mouarf) 
et on provisionne 0, soit le S.I. est troué et on provisionne 100%.


Et ça, les CAC, assureurs et autres risk-management ne veulent pas 
l'entendre, ce que je peux comprendre.


Les gars, gérer un S.I. en 2024, c'est passer au travers d'un anneau 
enflammé, en équilibre sur un fil, en monocycle, au dessus d'une fosse 
remplie de crocos. Il va falloir accepter que ca demande des moyens 
humains considérables.


Julien



Le 19/02/2024 à 23:02, Intermi Charles a écrit :

Je suis un ancien geek passé de l'autre côté de la rivière (plutôt côté audit 
généraliste que CaC)... Ce qui me donne un aperçu de l'attendu.
Je doute que le CaC s'intéresse réellement au fond du problème. Son objetif 
encore une fois est d'avoir ce qu'on apelle une assurance raisonnable. Peu 
importe la solution mise en place: ce qui importe, c'est que l'ensemble de la 
ligne, y compris les sous traitants de rang X, aient mis en place des mesures 
offrants cette assurance.
De ce fait, bien que les suggestions d'aller plus au fond du sujet soient, de 
notre point de vue de geek, intéressantes, car se recentrant sur la réalité de 
la problématique, elles ne me semblent pas pertinentes pour répondre à la 
question du CaC.
Donnons ce qui leur est nécessaire. Et ce qui est nécessaire, c'est ce que 
l'entreprise ne peut ignorer en terme de bonne pratique, c'est à dire 
aujourd'hui les recommandations de l'anssi (considérées tant dans le milieu de 
l'audit que des CaC comme le Graal).
Si vos réponses permettent de couvrir l'inquiétude quant à leur bonne prise en 
compte, vous n'aurez pas d'autre diligences. Et de mon expérience, il n'est pas 
si compliqué d'y repondre sans divulguer votre topologie de réseau interne ni 
les solutions en place.
Si vous avez régulièrement ce type de requêtes, ce qui peut être le cas si vous 
êtes sous traitant sur de nombreuses entreprises cotées, vous pouvez utilement 
répondre en mettant face à chaque recommandation anssi votre parade, et envoyer 
ce doc générique comme reponse à toute sollicitation (et indépendemlent de la 
demande des CaC, c'est un relativement bon exercice pour challenger votre mise 
en place).
Il ne faut pas prendre les CAC pour plus bêtes qu'il ne le sont : ces questions qui 
semblent tout droit sorties de google translator sont leur manière d'obtenir des réponses 
concrètes de la part d'entités n'ayant pas forcément votre vision globale des choses, et 
qui "rentre" dans leurs cases. Nombreuses restent les entreprises confiant leur 
sécurité SI à Duchmole, ancien responsable du nettoyage de surface...
Je ne doute pas que cette position évoluera dans les dix/vingt années à venir, 
selon l'équilibre des risques, tout comme les gros bureau de CaC ont désormais 
des spécialistes sur les risques marchés, les risques images...
Que la force soit avec vous,
Charles Bonnet.



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

Re: [FRnOG] [TECH] Recherche capteurs de pression d'eau LoRaWAN

[Julien Escario]

Bonjour Toussaint,

Le 20/02/2024 à 12:31, Toussaint OTTAVI a écrit :

Bonjour la liste,

S'il y en a qui bossent sur des réseaux d'eau, je cherche des 
références, et éventuellement des fournisseurs, pour des capteurs de 
pression d'eau en LoRaWAN :

- Pression : 0 à 30 bars
- Version avec avec alimentation externe et version auto-alimenté avec 
pile longue durée (j'ai les deux cas de figure, même si je vais 
privilégier les sites avec de l'énergie)
- Transmission LoRaWAN (soit directement, soit via une sortie bus 
interfaçable avec un émetteur LoRaWAN)

- De préférence, antenne externe, déportable à l'extérieur du coffret


Est-ce que tu sais préciser les diamètres des raccords sur lesquels il 
faut venir se brancher ? (Gardena, 3/4", conduite fonte 100mm, ...).


De même, environnement aérien chloré (par ex. dans un chateau d'eau) ? 
Ca impose des boîtiers non seulement étanches mais aussi les plastiques 
utilisés et des circuits complètement vernis (sinon tout rouille très vite).



En option, même question pour :
- Mesure de débit bidirectionnelle


Normalement, n'importe quelle solution devrait savoir faire dans les 
deux sens ou alors c'est une limitation purement software.



- Mesure de niveau dans des réservoirs d'eau potable
(j'ai déjà des références, mais j'en veux bien d'autres pour comparatifs)


Ah ah, j'ai justement un truc comme ça dans mes cartons pour ma commune 
(cf environnement chloré plus haut).


Désolé, pas de ref à te proposer, je peux juste de faire part des mes 
réflexions passées sur la question. Et LoRa(wan), je n'y ai pas encore 
touché, c'est pour le mois prochain (en attente du matériel de lab).
Je pense d'ailleurs m'orienter sur du meshtastic 
(https://meshtastic.org/) plutôt que LoRaWAN.


Bonne journée,
Julien


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

Re: [FRnOG] Re: [MISC] [Infosec] Incident de sécurité Orange Spain

[Julien Escario]

Le 06/01/2024 à 02:11, ml-fr...@srv.mx a écrit :

Bonsoir,

Pour Okta, pas besoin de spammer le MFA apparement 
https://www.reuters.com/technology/cybersecurity/okta-says-hackers-stole-data-all-customer-support-users-cyber-breach-2023-11-29/ :D


Cdlt


Encore ? Le nom me disait quelque chose : ils se sont fait tapés déjà en 
2022.


https://twitter.com/BillDemirkapi/status/1506107157124722690

C'est moi où une faille majeure par année ça commence à faire beaucoup 
pour une boite de sécu ?


Julien


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

Re: [FRnOG] [MISC] Limitation de puissance Linky : concrètement, c'est quoi ?

[Julien Escario]

Le 05/01/2024 à 10:37, Pierre DOLIDON a écrit :
Il existe des clés radio autoalimentées (tout le challenge est là, la 
prise ne distribue que 130mW maxi) qui permettent de récupérer les infos 
du TIC linky. comme la ZLinky_TIC par exemple (et c'est français en plus !)
j'ai la version avec antenne externe (compteur a +/- 10 mètres de la 
maison) et je dois dire que ça juste marche. toutes mes infos sont bien 
remontées (en zigbee) dans mon homeassistant, que je peux traiter 
ensuite comme bon me semble avec les smart-bidules


Alors, on dérive doucement du sujet initial mais je dois absolument 
citer le boulot formidable du G2ELab (Jérôme Ferrari) qui bosse 
activement sur la création de modules Linky en Wifi, Ethernet et Lora.

https://miniprojets.net/index.php/forum/

J'ai pu reproduire le Winky de Charles-Henri Hallard sur une breadboard 
plantée dans le boitier qui protège mon Linky : ca marche du feu de dieu.
Je suis en train de voir avec eux pour en fournir, intégré dans mon 
offre. J'imagine que CH2I devrait être en mesure d'en vendre en direct à 
l'unité d'ici peu de temps.


Le problème, c'est le wifi qui bouffe du coulomb sur une alim de 130mW 
en 50kHz (oui, oui, kilo) et ne fournit pas une portée fofolle.


La version Lora promet d'être vraiment très marrante ! Surtout si on 
peut utiliser un simple ESP32-lora en récepteur vers le LAN.


Bref, ce ne sont pas les options qui manquent pour exploiter la TIC.

Julien


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

Re: [FRnOG] [MISC] Limitation de puissance Linky : concrètement, c'est quoi ?

[Julien Escario]

Le 05/01/2024 à 10:12, Laurent Barme a écrit :


Le 04/01/2024 à 21:55, Julien Escario a écrit :

Le 04/01/2024 à 18:31, Paul Caranton via frnog a écrit :


…


Source : 
https://www.enedis.fr/faq/limitation-temporaire-de-puissance-electrique/comment-le-test-va-t-il-se-derouler


Alors, j'adorerais accéder à cette ressource mais Cloudfront semble 
avoir décidé que je n'étais plus digne de voir le site Enedis.


Comment Cloudfront pourrait-il bloquer ton accès à une page du site 
Enedis et pourquoi aurait-il pris une telle décision ?


Excellente question. J'ai systématiquement ce message :

"403 ERROR
The request could not be satisfied.
Request blocked. We can't connect to the server for this app or website 
at this time. There might be too much traffic or a configuration error. 
Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find 
steps to troubleshoot and help prevent this error by reviewing the 
CloudFront documentation.


Generated by cloudfront (CloudFront)"

Évidemment, aucune info de contact pour espérer corriger.

Utilises-tu un blocage de cookies ou un autre dispositif intermédiaire 
entre toi et enedis.fr ?


Houlà, un tas ! Après, j'ai testé avec un chrome (pour éliminer un 
plugin ou user agent qui ne lui plairait pas), depuis un autre poste et 
depuis un serveur extérieur avec wget. Même constat.


Bon après, qu'ils me jettent avec le user-agent de wget, je peux comprendre.

FDN étant mon FAI, je pense que la raison la plus logique serait que 
Enedis s'est dit que ce serait malin de mettre une liste de refus en 
mode 'tout ce qui ne vient pas des préfixes GP des 4 ou 5 FAI classiques 
français'.

Je suis un mauvais eyeball, que veux-tu.

Julien


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

Re: [FRnOG] [MISC] Limitation de puissance Linky : concrètement, c'est quoi ?

[Julien Escario]

Le 04/01/2024 à 22:40, Arnaud Launay a écrit :

Le Thu, Jan 04, 2024 at 06:01:45PM +0100, Toussaint OTTAVI a écrit:

La solution, pour éviter les délestages, c'est sans doute d'envelopper son
Linky dans du papier alu :-D
https://twitter.com/Pseudonymedispo/status/1390266949138096131


Ya plus simple, tu branches un UPS2000-G de chez Huawei, et tout ce qui passe 
en CPL,
que ce soit en local chez toi, ou du linky vers son serveur, ne passe plus. 
Enedis
n'a plus la main dessus du tout tant que tu laisses l'UPS branché (avec prises
allumées -- prises éteintes, ça fonctionne, mais du coup l'intérêt de l'UPS est
franchement limité...).


Euh, ca n'impliquerait pas de mettre l'onduleur ENTRE le Linky et le 
réseau ? Parce que ça, tu n'es pas censé pouvoir le faire sans risquer 
des poursuites ;-)



Après, c'est marqué dans la doc, donc difficile de leur reprocher:
https://support.huawei.com/enterprise/en/doc/EDOC1100079945

Page 3:

The UPS is of C2 (class A). If a C2 (class A) UPS is used in residential areas,
additional measures must be taken to prevent radio frequency interferences.


Il est marrant cet onduleur : "The leakage current of the 3 kVA UPS is 
less than or equal to 70 mA".
En gros : "laisse tomber la protection des personnes à 30mA et ne mets 
pas les doigts dans la prise"


Julien


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

Re: [FRnOG] [MISC] Limitation de puissance Linky : concrètement, c'est quoi ?

[Julien Escario]

Le 04/01/2024 à 18:38, Toussaint OTTAVI a écrit :
Parce que, si le truc se contente de ramener le calibre du breaker de 9 
kVA à 3 kVA comme un bourrin et sans prévenir l'utilisateur en aval, je 
crains que les résultats ne soient assez mitigés :-) Il serait pertinent 
que les informations concernant ce délestage à venir soient envoyées un 
peu avant via la TIC, afin de permettre à l'utilisation d'adapter sa 
consommation. Ceci étant, je ne sais pas si c'est prévu. La nouvelle TIC 
de Linky est apparemment plus évoluée que l'ancienne, mais à défaut de 
Linky à portée de main, je n'ai pas encore eu l'occasion de m'y pencher.


Ca s'appelle mode historique (1200 bauds) ou mode standard (9600 bauds). 
Je te confirme que le mode standard est vraiment beaucoup plus verbeux.


En historique, impossible d'avoir l'index d'injection par exemple.
Ceci étant, tu as tout de même l'info de préavis EJP, l'intensité 
souscrite, la période tarifaire en cours, etc ... [1]


Ca laisse pas mal de possibilités pour signaler que l'expérimentation 
est en cours.


Et sinon, le bon vieux contact sec qui permet d'asservir des appareils 
en mode tout-ou-rien.
Tiens, est-ce qu'il existe sur les (vieux vieux) compteurs mécaniques ? 
Et (vieux) électroniques ?


Julien

1 : https://www.enedis.fr/media/2035/download (merci Wayback machine)


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

Re: [FRnOG] [MISC] Limitation de puissance Linky : concrètement, c'est quoi ?

[Julien Escario]

Le 04/01/2024 à 22:28, Aurélien Rouzaud a écrit :

Hello,

Le jeu. 4 janv. 2024 à 22:22, Julien Escario <mailto:julien%2bfr...@lesours.in>> a écrit :


Très juste. Mais l'abo 3kVA n'existe plus. Min 6 kVA désormais sauf
dans
le cas spécifique de l'expérimentation qui nous intéresse. Ce qui me
fait dire que ca risque de faire bizarre à certains.


L'abonnement 3kVA existe toujours, c'est uniquement dans le cas de 
l'option Heure Pleine / Heure Creuse que c'est 6kVA minimum.


Très juste, mea culpa. Pas de 3kVA en HPHC et en Tempo mais elle existe 
bien toujours en option base.


Julien


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

Re: [FRnOG] [MISC] Limitation de puissance Linky : concrètement, c'est quoi ?

[Julien Escario]

Le 04/01/2024 à 18:06, David Ponzone a écrit :

Euh Kelwatt, c’est un comparateur qui doit toucher sa petite commission, donc 
c’est un gros putaclics non ?
A partir de là, il faut prendre le contenu sur le site avec autant de pincettes 
que si ça venait de Trump.


J'avoue avoir pris les premiers articles pertinents sans paywall qui 
sortait de ma recherche mais une recherche complémentaire montre que 
diverses sources racontent la même chose dans les grandes lignes.


La prochaine fois, je donnerais un lien vers la recherche mais je doute 
que beaucoup se donnent la peine de cliquer sur les liens proposés.


Julien


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

Re: [FRnOG] [MISC] Limitation de puissance Linky : concrètement, c'est quoi ?

[Julien Escario]

Le 04/01/2024 à 18:30, Ducassou Laurent a écrit :

Hello,

Il y a bien un Organe de coupure (contacteur) dans le linky. La doc le 
confirme !


Comme tu le dis, la population générale ne sais pas faire la difference 
entre kW (puissance instantannée) et kWh (puissance "tiré sur une 
periode" facturé) et tu oublie le kVa qui a toute son importance ici ! 
Notre ami Cosphi le comeback avec la mesure du déphasage qui va avec !


Un radiateur electrique à un cosphi de 0.99/1  : 1kW consommé ) 1kVa !
Par contre... Une PAC c'est un moteur, donc des condensateurs ! Donc le 
Cosphi n'est pas de 1 ! mais on concidère 0.95 à pleine charge (et 
souvent entre 0.8 et 0.90 en "régulation inverter") donc une PAC de 2kW 
de puissance soutiré (pas restitué !) aura un tirage max de 2*0.95 => 
1.9kVa ! Max...
Un ordinateur... lui le cosphi moyen est vers 0.8  de mémoire... Donc 
0.200kW tiré = 0.160kVa...

(on va pas parler d'une ampoule LED qui tombe même à 0.6 de cosphi !)


Alors c'est gentil pour le cours de physique appliquée en élec mais tant 
qu'à faire, autant éviter de raconter n'importe quoi :


S = U.I
P = U.I.cosphi
ou P = S.cosphi

Donc la valeur absolue de la puissance utile (P) est inférieure à celle 
de la puissance apparente (S) quand cosphi < 1 (ce qui est vrai dans la 
plupart des cas).


Si la plaque signalétique de ta PAC annonce 2kW, cosphi 0.95, c'est 2,1 
kVA qu'il faut prévoir mais on te facturera toujours en kWh.


Une bonne analogie pour s'en souvenir (un classique) : 
http://www.electromagazine.ch/wp-content/uploads/2018/07//beer-1669273.png 
(source [1]) .


Et pendant qu'on y est : les condensateurs AUGMENTENT le cos phi. Ce 
sont les selfs (bobines, enroulements de moteur notamment) qui le font 
diminuer. Il n'est pas rare en industriel que l'on doive rajouter des 
batteries de condos pour remonter le cosphi (à la demande d'Enedis).
Certains contrats prévoient également la facturation par Enedis de la 
puissance réactive.


Que ce passe t'il si on tira 4kVa sur un abonnement 3kVa? C'est 
possible!  Le fameux Puissance appliquée : "Pcoup"
Dans la documentation ENEDIS du linky est précisé les puissance de 
coupure :

1.1*Abonnement : Sans limite ==> jusqu'à 3.3 (3kVa abonnement)
1.4*Abonnement : pendant 250s ==> jusqu'à 4.2 (3kVa abonnement)
2.5*Abonnement : 40s ==> jusqu'à 7.5 (3kVa abonnement)


Très juste. Mais l'abo 3kVA n'existe plus. Min 6 kVA désormais sauf dans 
le cas spécifique de l'expérimentation qui nous intéresse. Ce qui me 
fait dire que ca risque de faire bizarre à certains.


Julien

1 : http://www.electromagazine.ch/fr/courant-reactif-2/


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

Re: [FRnOG] [MISC] Limitation de puissance Linky : concrètement, c'est quoi ?

[Julien Escario]

Le 04/01/2024 à 18:31, Paul Caranton via frnog a écrit :

Bonjour,

Oui il y a bien un organe de coupure qui permet de couper le courant dans pas 
mal de cas :
- Dépassement de puissance souscrite
- Dépassement de puissance lors d'un délestage (ce qui est l'objet du test, ce 
n'est pas implémenté nationalement pour le moment)
- Dépassement de puissance limitée en cas de mauvais paiement
- Mauvaises conditions du réseau Enedis (surtension, rupture de neutre...)

Pour le test on parle bien d'une coupure en cas de dépassement de 3kVA. Il y a 
cependant des marges, le Linky ne saute pas à 3kVA exactement. Il saute s'il y 
a un dépassement de puissance supérieur à 1,1*Pn (avec Pn = 3kVA) pendant 250 
secondes, ou un dépassement de puissance supérieur à 1,4*Pn pendant 40s 
secondes, ou immédiatement au delà de 2,5Pn.

Il est ensuite possible de le réarmer manuellement, ou il sera réarmé à la fin 
des 2h de test automatiquement.


Ah ! Donc le gestionnaire de réseau peut également réarmer le Linky à 
distance. Voilà qui est particulièrement intéressant et va probablement 
sauver pas mal de denrées périssables ... et déplacement de techs.


J'ai lu plus haut que l'expérimentation était en opt-in. Hors, j'ai lu à 
plusieurs reprises que c'était l'inverse : il faudra explicitement 
demander à ne pas y participer.


Je ne sais pas si les abonnements pro sont également concernés mais si 
c'est le cas, qui parie que certains courriers n'arriveront jamais 
jusqu'à la personne qui gère le point haut télécom pour qu'il puisse 
s'opposer ? Parce que 3kVA en radio, c'est vite avalé.



Source : 
https://www.enedis.fr/faq/limitation-temporaire-de-puissance-electrique/comment-le-test-va-t-il-se-derouler


Alors, j'adorerais accéder à cette ressource mais Cloudfront semble 
avoir décidé que je n'étais plus digne de voir le site Enedis.


Merci pour ces précisions, on y voit déjà plus clair.

Julien


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

[FRnOG] [MISC] Limitation de puissance Linky : concrètement, c'est quoi ?

[Julien Escario]

Bonjour,
Permettez de rebondir sur un sujet pas mal évoqués fin 2022 quand il y 
avait des risques de blackout sur le réseau.


A priori, l'expérimentation consistant à limiter la puissance des Linky 
se précise puisque c'est le Puy-de-dôme qui s'y colle [1].


Je ne trouve cependant aucune info technique sur la façon dont c'est 
fait. Limitation à 3kVA, je veux bien, mais que se passe t'il si on tire 
4 kVA ?
Je ne vois aucune autre solution que de couper. Hors, il m'avait semblé 
lire ici que le Linky n'avait pas d'organe de coupure.

Pourtant je lis ici [2] qu'il arrive de devoir réarmer le Linky.

Si effectivement ça coupe, cela signifie que l'on va avoir tout un tas 
de foyers dont l'électricité risque d'être coupée pendant de longues 
heures si c'est en plein milieu de la journée et qu'il n'y a personne.
Je pense notamment à ceux qui ont des PAC qui tirent au moins 2kW voire 
beaucoup plus pour certaines.
Encore mieux pour ceux qui sont absents (+72h) et risquent de se 
retrouver avec un élevage de champignons dans le frigo/congèlo.


Je doute que ceux là se contentent des 10 balles de prime (quoique, ils 
n'auront probablement pas le choix).


A toute fin utile, je rappelle qu'en population générale, une écrasante 
majorité de nos concitoyens ne fait pas la différence entre un kW et un kWh.


L'un de vous aurait-il un éclaircissement ?

Merci et bonne année (même si en un unixtime, ca ne signifie rien),
Julien

1: 
https://www.tomsguide.fr/linky-on-connait-enfin-le-departement-ou-aura-lieu-le-test-de-black-out-de-200-000-foyers/

2: https://www.kelwatt.fr/guide/compteur/electricite/rearmer-linky


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

Re: [FRnOG] [TECH] problème PDU : courant de fuite

[Julien Escario]

Le 09/10/2023 à 19:18, fr...@r0m5.eu a écrit :

Bonsoir,


Bonjour !

Je rencontre actuellement un soucis dans une baie informatique avec une 
arrivée 32A, hors datacenter, qui dispose d'un PDU manageable d'une 
marque reconnue et présente sur le marché datacenter.


Nous essayons d'utiliser ce PDU en y reliant 15 alimentations de switch 
réseau 350W (pas junisco mais grande marque réseau tout de même) qui ont 
chacune un peu plus de 1mA de courant de fuite.
Lorsque nous relions ces alimentations au PDU déjà démarré (contrôleur 
démarré et outlets déjà alimentées) pas de soucis.
Par la suite lorsque le courant est coupé en amont du PDU, alors au 
retour du courant notre différentiel 30mA saute systématiquement.
Nous avons mesuré que lors du démarrage du PDU, on a un courant de fuite 
de 8 à 10mA supplémentaires, courant de fuite qui disparaît une fois le 
contrôleur du PDU démarré et les relais actionnés (les outlets 
alimentées). On revient alors au seul courant de fuite des alims de 
switch (entre 15 et 20 mA).


Petite remarque en passant : la bonne pratique avec des PDUs voudrait 
qu'au redémarrage du PDU après incident, tu actives les outlets un par 
un avec 5 à 10s de décalage (suivant ce que tu peux te permettre) de 
façon à limiter l'appel de courant.


Dans mon souvenir, c'est faisable dans la conf des PDUs.

Bon, certes, depuis qu'on ne met presque plus de disques rotatifs, les 
pics d'appels sont moins violents mais quand même ...


Le soucis 'moderne' c'est qu'avec les IPMI/DRAC/whatever, les PDUs avec 
outlet 'switchables' commencent à perdre de leur intérêt et finissent 
plus par être un PoC qu'une plus-value.


Julien


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

Re: [FRnOG] [BIZ] Déstockage Sniffing -> Surveillance qualité réseau électrique

[Julien Escario]

Bonjour,

Le 20/09/2023 à 21:31, Toussaint OTTAVI a écrit :


Le 20/09/2023 à 15:25, Stéphane Rivière a écrit :
Vraiment une super idée... Si vous allez plus loin, je suis à l'écoute 


Cher confrère îlien, tu me vouvoies maintenant ? :-) En fait, comme tout 
bon Corse qui se respecte, je suis flemmard, j'attendais que quelqu'un 
le fasse pour moi :-)


Plus sérieusement, pour la maison, j'ai un peu passé l'age de faire des 
trucs bizarres reliés au secteur. Et pour les applications 
industrielles, quelqu'un qui se reconnaîtra m'a conseillé çà :


https://www.socomec.fr/fr/p/diris-a-40

Cà fait le job de supervision de tension / fréquence, et à priori, çà 
mesure même la "propreté harmonique". Il y a une interface IP/Web, un 
nuage pour ceux qui craignent le soleil, et pour les autres, çà se 
récupère bien pour envoyer dans un TSDB + grapheur de son choix. En en 
mettant deux sur deux postes différents, çà peut même permettre de voir 
des défauts sur la HTA.


Une fois n'est pas coutume, je vais me faire une rapide pub pour mon 
dernier truc en date (c'est marqué BIZ après tout).


Le besoin est de mesurer/grapher en détail les différents consommateurs 
de puissance dans un bâtiment.


Il y a plusieurs façons de faire ça, en effet : le linky te file pas mal 
d'informations quand il est en mode standard en effet. Le mot magique 
chez EDF : "formulaire Enedis F185".


Ensuite, un optocoupleur, un ESP32 et trois résistances plus tard (cf 
https://raw.githubusercontent.com/hallard/WeMos-TIC/master/pictures/WeMos-TIC-sch.png), 
tu obtiens ce genre de chose :

https://pix.milkywan.fr/XhaQu0Oo.png

Là, c'est la représentation de Home Assistant à partir de sa petite base 
sqlite mais c'est aussi poussé dans influxdb pour stockage à long terme 
et visualisation avec Grafana.
Et évidemment dispo pour les 3 phases, le cas échéant. Plus tout une 
trétachiée d'infos type période tarifaire en cours, puissance souscrite, 
consommation par période tarifaire, courant efficace, énergie réactive.


En revanche, l'alim fournie par le Linky est tellement ridicule qu'il 
faut alimenter l'ESP32 à côté. Suivant l'emplacement du compteur, ca 
peut vite être compliqué. J'ai un truc dans les cartons pour rajouter 
une batterie/une supercapa/un panneau solaire.



Et pour être plus précis et avoir des mesures plus fréquentes (< 10s), 
j'ai fait un léger redesign du Expandable 6 Channels ESP32 Energy Meter 
de CircuitSetup 
(https://github.com/CircuitSetup/Expandable-6-Channel-ESP32-Energy-Meter) 
qui permet de mesurer la tension à base d'un convertisseur 230V/9V (mais 
il faut prendre 4 secs à l'étalonner avec un multimètre).


Et pour le coup, ca mesure aussi la fréquence au dixième de Hz : 
https://pix.milkywan.fr/1SG1HszE.png .


En bonus, la possibilité de mesurer de 6 à 42 départs électriques avec 
des transfos de courant à noyau coupé (courant, puissance 
active/réactive/apparente, cos phi, énergie incrémentée).


La techno est prête, je suis en train de peaufiner la comm' mais ce 
qu'il me manque le plus pour le moment, c'est de le confronter à un 
usage réel. Je ne l'avais pas pensé à destination d'un DC/salle serveurs 
mais pourquoi pas. Si vous avez des use-case à me soumettre, je prends !


Etant donné que ce sont des pinces non-invasives, ca ne créera pas de 
SPoF sur la chaîne électrique tout en restant à bonne distance des serveurs.


Donc pas mal de solutions possibles avec ou sans Linky finalement.

Julien


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

Re: [FRnOG] [TECH] Raccordement entre 2 bâtiments à 150m l'un de l'autre

[Julien Escario]

Le 21/08/2023 à 15:40, Martin a écrit :

Bonjour à tous,


Bonjour,


un client dispose de 2 bâtiments espacés l'un de l'autre de 120m environ.
Jusqu'à maintenant, chaque bâtiment disposait d'un lien ADSL. L'un des 2
bâtiments est désormais éligible à la fibre, mais pas l'autre (adresse
unique, campagne profonde, petit bureau dans grand entrepôt, ...).

Je souhaite donc lui mettre la fibre sur le bâtiment principal et créer un
lien avec l'autre bâtiment qui a impérativement besoin d'un accès internet.

J'avais dans un premier temps envisagé un pont wifi, le terrain étant
dégagé. Mais il se trouve après prise de renseignements qu'il y a une gaine
technique avec regards, etc... et que je peux donc envisager une solution
filaire.


C'est une excellente occasion en effet ! Ta liaison inter-bâtiment aura 
toujours un taux de panne ridiculement faible par rapport à ton 
FTTH/ADSL/WAN-tever.



Les bâtiments sont espacés de 120m environ, et j'estime à 150m la longueur
de "câble" nécessaire pour relier 2 équipements réseau.

Pour du cuivre, cette longueur me semble trop importante, je me trompe ?


Oui et non mais en 2023, en inter-bâtiments, la fibre s'impose. En 
cuivre, tu seras limité à 10Gps (peut être 25Gbps et encore). Je doute 
qu'on cherche à normaliser des débits supérieurs dans un proche avenir, 
l'intérêt étant très faible (ou alors les ports vont coûter un bras).



La fibre me semble en outre être un bon choix (moins sensible à l'humidité,
plus pérenne, performant et évolutif), mais je connais peu les solutions et
contraintes sur une telle longueur.


En fait, tu n'en as quasiment aucune. 150m en fibre, ça se gère 
*presque* comme si c'était 5m.



Quel est selon vous le meilleur choix :
- de fibre


Alors je milite depuis plusieurs années pour qu'on arrête de mettre de 
la multimode. La monomode ne coûte plus rien et n'est pas limitée en 
débit (dispersion, toussa).


Donc les mots magique ici sont G652 ou G657. Je ne suis pas spécialiste 
mais je vois déployer systématiquement de la G657 depuis pas mal de temps.



- de connecteur


Là, aussi, tu es libre. Les standards les plus 'visibles' sont SC et LC. 
le ST n'a plus tellement court même si ça ne serait pas rédhibitoire.

Je pars du principe que l'encombrement dans ta baie n'est pas un problème.


- d'équipement réseau : je vais avoir des routeurs mikrotik aux 2 bouts,
pour gérer les différents besoins du client (plusieurs wifi, plusieurs
réseaux, etc...), est ce qu'un SFP dans le routeur est le meilleur choix
car le plus simple ?


IMHO :
- Déploie un 12 ou 24 brins G657 que tu fais arriver sur des bandeaux 
SC/APC dans une baie de chaque côté. Toutes les paires soudées et 
disponibles.

- Achète quelques jarretières SC/APC vers LC
- Plante des optiques 10G (LC) dans les krotik (tu peux mettre n'importe 
quelle constructeur)

- Croise les RX/TX en branchant les jarretières, ca devrait monter

En bonus : trouve un stylo optique, un truc qui clignote rouge et sur 
lequel tu peux brancher une jarretière. Ca coûte 10 balles et ca va te 
faire gagner 4 heures.


Avec un peu de démerde, tout ça se fait seul en apprenant sans aide 
extérieure. Il n'y a rien d'extrêmement technique.

Sauf si tu veux te débarrasser du problème, bien entendu.

My 2 cts,
Julien


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

Re: [FRnOG] [MISC] Le Cloud

[Julien Escario]

Bonjour,
A $job-1, j'avais mis en place Proxmox + Ceph + Proxmox Backup Serveur.
C'est vraiment hyper efficace et scalable.

Finalement, la seule qui manquait c'était l'orchestration. L'auto-scale 
on y arrivait doucement avec pas mal de choses possibles à chaud (RAM, 
CPU et disque).


Pas vraiment fan de la partie H.A., faute de bonne expérience avec le 
self-fencing.


Et pour ceux qui veulent se couvrir, il y a toujours moyen de payer pour 
avoir du support, ca sera toujours infiniment moins cher que "l'ordi 
d'un autre".


Ceci étant, j'ai l'impression qu'ils ont violemment ralenti le rythme 
des nouvelles features depuis environ un an. J'ignore pourquoi. Peut 
être pour se concentrer sur la partie SDN.


My 2 cts.

Julien

Le 28/02/2023 à 20:44, John Secu a écrit :

Article très intéressant mais par contre aucune information sur la solution
de stockage (hyper convergence?) et surtout de sauvegarde.

Pour le stockage, je sais que des entreprises qui utilisent ceph (
https://docs.ceph.com/en/quincy/) qui semble être une solution prometteuse.

Pour le backup dans un datacenter, je n'ai pas vraiment connaissance de
solution open source efficace.

Quelqu'un a une suggestion ?

Hervé

Le mar. 28 févr. 2023, 19:02, Stéphane Rivière  a écrit :






https://www.cio-online.com/actualites/lire-basecamp-sort-du-cloud-et-economise-plus-de-6-5-meteuro-sur-5-ans-14771.html
Merci Rod. Ça fait chaud au cœur de lire ça. Il y a encore des gens avec
cerveaux dans ce métier. À l'insu de notre plein gré, on est devenu des
spécialistes (si l'on peux dire) d'évacuation d'AWS (& autres
clouderies) vers des infras classique et beaucoup plus économiques -
classiquement /3 mini de la facture et perf des instances x3).

Par ailleurs, un serveur Dell, au bout de 10 ans, il est en forme pour
encore 10 ans. Après c'est une question de conso du hardware et de perf
des langages utilisés.

Article original (à suivre)

https://world.hey.com/dhh/we-stand-to-save-7m-over-five-years-from-our-cloud-exit-53996caa

--
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/



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

Re: [FRnOG] [MISC]

[Julien Escario]

Le 08/01/2023 à 11:01, kazuhiro oguchi a écrit :

Bonjour

Un cas complètement personnelle.
Nouvelle maison dans les Landes par un constructeur.
Donc résultat pas d'adduction.
Naïvement je suis passé par https://maison-individuelle.orange.fr/
[...]
Bonne journée
Kazu


Bonjour,
Intéressant ça : le constructeur/promoteur n'a pas obligation (légale ou 
contractuelle) de fournir l'adduction réseau d'eau, d'électricité, etc ?

Internet

D'autant plus que, sauf erreur, la connexion Internet est considérée 
comme un droit fondamental. De mémoire, au moins en droit européen, pas 
forcément transposé en droit français. Les juristes me corrigeront.


Ca rejoint la définition d'un terrain viabilisé : adduction eau, égout 
(ou assainissement individuel), gaz (le cas échéant), électricité et ... 
telecom.


Et autant on peut vendre un terrain non viabilisé, je doute fortement 
que l'on puisse vendre une maison neuve sur un terrain qui ne le soit pas.


Tout ça pour dire que je commencerais par regarder l'obligation légale 
du constructeur de fournir l'adduction telecom avant de faire faire des 
devis de GC. Après, il y a les histoires maître d’œuvre ou d'ouvrage, ca 
peut tout changer à ce niveau.


Julien


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

Re: [FRnOG] [TECH] Résolution inverse puis directe d'une IPv4 routable pro

[Julien Escario]

Le 13/12/2022 à 23:39, Richard Klein a écrit :

 >Alors, pardon, mais déjà, l'expérience a montré que 'pro' n'existe pas
 >d'un point de vue technique chez les opés. C'est un terme qui n'a qu'une
 >portée commerciale, le service étant le même que grand public, modulo un
 >service client un chouilla plus efficace chez certains (et encore).
Je me permet de te contredire car effectivement le "PRO" est utilisé par 
le commercial et largement déformé mais les flux data pour les pros sur 
des lignes mobiles ne passent pas toujours aux mêmes endroits pour le 
mobile .

Je commence par l'APN et le QCI.
Après le coeur mobile n'est pas ma spécialité mais entre ma ligne GP et 
une ligne pro les sondes montrent que "nous n'avons pas les mêmes 
valeurs !  " 


Et tu fais bien : je n'avais pas pensé au mobile. La remarque reste 
valable pour le fixe cuivre & surtout F.O.


Julien


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

Re: [FRnOG] [TECH] Résolution inverse puis directe d'une IPv4 routable pro

[Julien Escario]

Le 13/12/2022 à 17:19, Albert ARIBAUD via frnog a écrit :

Bonjour,

Question vue du côté client (pas grand public, pro, mais ne bossant pas
dans le domaine du réseau) à propos d'IPv4 routables qu'on nous fournit
:


Alors, pardon, mais déjà, l'expérience a montré que 'pro' n'existe pas 
d'un point de vue technique chez les opés. C'est un terme qui n'a qu'une 
portée commerciale, le service étant le même que grand public, modulo un 
service client un chouilla plus efficace chez certains (et encore).



Est-il normal/usuel/courant/autre que le reverse d'une IP routable à
usage pro ne retourne rien (opé 1) ou qu'il soit défini par l'opé mais
que la résolution directe du FQDN renvoyé ne retourne rien (opé 2) ?

Je suis surtout étonné du cas opé 2 : il a le contrôle de la zone
inverse de l'IPv4 fournie (il nous l'a démontré), mais, et je ne
comprends pas pourquoi, il met par défaut dans cette zone des FQDN vers
un domaine dont il ne contrôle pas la zone directe...

(NB : je sais bien que pour opé 2 -- et peut-être opé 1 -- une/la
solution est de leur faire ajouter un PTR dans leur zone de reverse de
leur IP vers un FQDN d'un domaine dont nous contrôlons la zone et nous
charger nous-même de mettre un A dans la dite zone ; j'aimerais juste
éviter de mettre dans notre zone des entrées destinées seulement à
réparer les limitations de mon fournisseur.)


La bonne pratique voudrait que les opés définissent un reverse 
'génerique' (par ex. basé sur l'IP) vers une zone directe qu'ils 
contrôlent. C'est le cas la plupart du temps.


Et ensuite laissent la possibilité de configurer ce reverse à la demande 
du client. Là aussi, la procédure passe le plus souvent par un ticket au 
support, jamais la procédure n'est en self service via un espace client. 
En tout cas, jamais vu, même en hosting.


De toute façon, ca ne vaut pas le coup, il n'y que les geeks qui veulent 
encore s'emmerder avec le mail pour avoir besoin d'un PTR propre. Espèce 
en voie de disparation avancée.


Pointer le PTR sur une zone qu'ils ne contrôlent pas me paraît pour le 
moins audicieux. Il doit même y avoir quelques trucs sales à faire avec 
les domaines active directory dans ce cas là mais je suis loin d'avoir 
les compétences pour en dire plus.


Julien


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

Re: [FRnOG] [MISC] Les telecoms et l'électricité

[Julien Escario via frnog]

Le 06/09/2022 à 09:32, Richard DEMONGEOT a écrit :
> [...]
> Je me trompes peut être, mais j'ai tendance à croire que les téléphones
> fixes sont voués à disparaître pour les particuliers.
> Tout le monde possède un téléphone portable voir un smartphone; qui lui
> est sur batterie. Donc capable de tenir les 2h de coupures - délestage
> prévisible en cas de crise sur le réseau électrique.

Ca c'est burné comme affirmation : je connais quelques personnes qui
n'ont pas de téléphone portable. Essentiellement des 60 ans et + mais
les exclure d'office me paraît carrément audacieux !

Et même, (c'est un ressenti, pas une étude objective) mais les retraités
de mon entourage qui ont un téléphone portable (je ne parle pas de
smartphone) l'ont souvent prit par sécurité pour aller au bois.

> Donc dans le contexte de la crise actuelle et prévisible, la box
> internet n'est - à mon sens - pas vitale pour 99.99% des cas.

Alors navré mais des généralisations comme celle là sont très vite
dangereuses. Les urgences/sapeurs pompiers/samu n'interviennent pas pour
99,99% de la population mais bien pour 100%.

Ca va être sympa quand il va falloir annoncer à une veuve que son mari
est mort parce qu'ils n'avaient pas de téléphone portable.

Et même en considérant 100% de la population équipée en portables, ça ne
règle rien : ici, à la première coupure du jus, on perd le mobile.

Si, en ville, les points hauts sont souvent équipés de batteries qui
tiennent quelques minutes voire de groupes pour de plus longues durées,
dans la brousse c'est rarement le cas.

Ici, plus de jus, c'est plus de secours efficaces*, point barre.

J'ajouterais qu'en cas de coupure généralisée d'un secteur de plus de
5000 habitants, il est probable que le SDIS local sera de toute façon
débordés d'appels, essentiellement lié à la panique.

Julien

* efficaces au sens où il faudra que les habitants se démerdent pour
faire quelques kilomètres. Pas insurmontable mais ça peut être suffisant
pour décider de la survie ou non.

P.S. : c'est hors sujet mais je me demande si la situation n'est pas
dramatisée. D'ici les pics de consommation, on va avoir des tranches qui
devraient être redémarrées. Peut être pas les 1450MW qui ont un défaut
d’étanchéité mais celles qui sont sur des maintenances planifiées.


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

Re: [FRnOG] [MISC] Les telecoms et l'électricité

[Julien Escario via frnog]

Le 05/09/2022 à 19:36, Paul Caranton a écrit :
> [...]
> Il ne reste plus qu'à exploiter la TIC s'il est nécessaire d'avoir du
> temps réel. Et encore, le Linky ne fournit (malheureusement) que la
> puissance apparente instantanée, et non la puissance active. Je n'ai
> jamais compris pourquoi...

Alors c'est marrant, je viens de passer la journée à bidouiller pour
exploiter la TIC (un truc dans ma todo depuis plusieurs semaines).

C'est plutôt simple en effet : un ESP32, une résistance et un
optocoupleur (1). La galère est dans le choix de la valeur de la
résistance en fait : j'ai dû virer la résistance R1, mon Linky sortant
0,1V AC entre I1 et I2 (?!?).

Demain, c'est passage en mode standard (je produis en PV) et tentative
d'alimentation à partir de la borne A du TIC.

Mon objectif était DIY mais si vous voulez pas y passer 2/3 jours, il
existe des modules pour à peu près tous les protocoles IOT (zwave,
zigbee, wifi, même lorawan à priori).
Le plus précis de tout ce que j'ai vu :
https://www.tindie.com/stores/hallard/
Et probablement le moins cher (et open-hardware/software).

Si certains sont partageurs, je prends volontiers les valeurs VAC que
vous avez entre I1 et I2 sur la TIC (2 min et un multimètre), merci !

Bonne soirée,
Julien

1 :
https://clubdomotiqueairbuspalays.files.wordpress.com/2017/01/ntfh03-teleinfo.pdf


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

Re: [FRnOG] [TECH] [TECH] Distribution horizontale d'un bâtiment : Cuivre ou Fibre ?

[Julien Escario]

Le 30/06/2022 à 10:43, David Ponzone a écrit :

Ok mais ça revient justement au cas dont je parlais: quand le vertical se 
prolonge en horizontal, et là, poussé à l’extrême.
Après ça veut dire gérer par un switch par table, donc une alim, des cordons 
fibre plus fragiles que du cuivre, des connecteurs plus fragiles, une prise 
femelle fibre (plancher ou sur la table directement ?) plus fragile aussi.
Je pense que ça dépend de la population d’utilisateurs qu’on a, et des meubles 
aussi (des super tables/bureaux neufs, avec une petite trappe pour planquer la 
prise fibre et le switch par exemple).
Ca serait intéressant d’avoir un RetEx de Philippe, un peu plus complet que son 
PowerPoint, concernant les emmerdes qu’il faut gérer, est-ce qu’ils avaient pas 
justement changé tous les meubles aussi au passage, et le type de population 
concerné (grande différence entre utilisateur final et gens qui bossent dans 
l’IT).


Bon, je crois qu'on est tous d'accord sur le fait qu'il mettre de la 
fibre jusqu'au dernier hop avant le poste. En profiter pour mettre de la 
monomode et tirer du 24 FO (max à ma connaissance sur un bandeau 1U) pas 
beaucoup plus cher du 2 ou 4 FO.


En version luxe, tirer deux adductions pour chaque switch terminal via 
deux chemins différents quand c'est possible.


Par contre, sur le poste, CAT7 aujourd'hui et basta. Y'aura tout le 
temps de changer la distribution le jour où la fibre jusqu'au poste se 
démocratise (10 ans ? 15 ans ? jamais ?).


Perso, je vois mal le eyeball manipuler des jarretières LC sans les 
exploser au bout de deux jours (cf le mec qui roule avec sa chaise sur 
le RJ45).


Julien


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

Re: [FRnOG] [ALERT] Coupure long haul

[Julien Escario]

Covage, pour sa part, remonte un fiber cut volontaire (vandalisme) à 
Souppes-sur-Loing. Ca fait au moins 100km de Mareuil-lès-Meaux.


Ca ressemble de plus en plus à soit un vandalisme très bien organisé 
soit un go-fast en mode destruction de chambres.


Quelqu'un a t'il commencé à lister les coordonnées des différentes 
réparations en cours ? Est-ce qu'il faut demander aux ukrainiens de 
renvoyer quelques soudeuses ?


Julien

Le 27/04/2022 à 15:47, Clement Cavadore a écrit :

On Wed, 2022-04-27 at 09:47 +0200, Clement Cavadore wrote:

J'ai un Paris-Bruxelles de down, et DE-CIX a perdu un Francfort-NYC
cette nuit, j'imagine que ca pourrait être lié:

"Currently, the link between NYC1 and FRA12 is down and that is
causing link saturation between NYC2 and FRA6. We are investigating
the issue and we are in touch with our vendor. We will update you
with our findings."

Les derniers updates de DE-CIX:

UPDATE 2022-04-27 13:44 UTC:
Cables have been cut inside the chamber and they have called out their
repair team and contractors have reached the site and confirmed the
break was due to vandalism(sabotage).
As per the update from the provider, the cut has been localized between
Mareuil-lès-Meaux & Paris and the provider has engineers on site
troubleshooting. We will update you with new info ASAP.

UPDATE 2022-04-27 13:02 UTC:
As per update from provider, cut has been localized between Mareuil-
lès-Meaux & Paris. Repair team is now engaged and awaiting ETA, further
updates to come.


--
*Julien Escario*
Technicien Informatique

julien.esca...@altinea.fr
Tel direct : 03 74 39 10 21
Support : 09 70 75 44 25

Logo Altinea
*Conseils & Infrastructures
Informatiques*

Accueil : 03 74 39 10 20
9 Rue du faubourg 39570 Nogna
*www.altinea.fr <https://www.altinea.fr>*

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

[FRnOG] [TECH] eos 4.18, VRRP et router advertisement

[Julien Escario]

Bonjour la liste,

J'ai un comportement que je pense être un bug sur eos 4.18 (oui, c'est 
vieux mais c'est tout ce que j'ai).


Je tente de faire du VRRP (pas VARP) sur IPv6 sur un VLAN. J'ai donc 
toute ma conf avec deux IPv6 dans le même subnet et une conf de ce style :


vlan100
   ipv6 address a:b:c:d::fe/64
   ipv6 nd ra suppress all
   vrrp 51 priority 200
   vrrp 51 ipv6 a:b:c:d::1
   vrrp 51 ip version 3

Et pareil sur l'autre arista mais IP en a:b:c:d::fd et priorité 150.

Notez le suppress *all* . Maintenant, quand je bascule la priorité VRRP 
du Arista maître (disons 100), j'ai un RA qui déboule en sortie du VLAN 
et me bousille le routage des machines qui l'acceptent.


Alors que ça ne devrait pas arriver, nan ?

Le plus fun : lorsque je remets la priorité à 200, je n'ai *pas* de RA.

Et vice-versa si je modifie la priorité du backup. C'est toujours 
lorsque l'Arista sur lequel je ne fais pas la conf passe Master que j'ai 
l'émission d'un RA.


Ca ressemble tellement à un bug que j'aimerais voir si l'un d'entre vous 
peut confirmer ça (disons que si quelqu'un a déjà rencontré ça, il est ici).


Pour le moment, la seule solution que j'ai trouvée c'est de mettre 'ipv6 
nd ra lifetime 0' : ça envoi toujours des RA mais au moins ils ne 
chamboulent pas mes machines sur le LAN.


Merci pour vos lumières (histoire que j'arrête de me retourner la tête 
et puisse passer à autre chose),


Julien


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

Re: [FRnOG] [MISC] Utilisation des fourreaux télécom Orange ?

[Julien Escario]

Le 30/03/2022 à 12:21, François Lacombe a écrit :
> Il faut répondre à la question 1 et décider en fonction
> * Les fourreaux sont à la commune, pas de problème pour tirer du câble
> dedans a priori
> * Les fourreaux sont à quelqu'un d'autre, il faut se renseigner sur
> l'existence ou non d'une offre de location (qui doit normalement exister
> aux termes du L34-8-2-1 CPCE notamment)

Dans tous les cas : soit le GC appartient à la collectivité (comcom,
commune), soit elle appartient à un opé privé qui doit par conséquent
payer la RODP ou est-ce que je dis une grosse bêtise ?

Et si le fourreau appartient à la collectivité, est-ce qu'elle a
également l'obligation de proposer une offre de location ?

Merci !

Julien



OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] Problèmes envoi de mail vers GMAIL

[Julien Escario]

Le 08/03/2022 à 12:13, Hugues Voiturier a écrit :

Mine de rien, c'est de plus en plus problématique ces politiques de plus en
plus dures de filtrage.

Suffit de respecter les bonnes pratiques, SPF/DKIM et DMARC en bonus ça règle 
déjà bien des soucis.


Merci Hugues.

DKIM, c'est un peu plus complexe mais SPF, c'est juste un enregistrement 
DNS après identifier les serveurs susceptibles de faire sortir du mail 
pour ton domaine.


Ca fait quand même gentiment 10 ans que tout le monde explique qu'il 
faut s'y mettre.



Forcément qu’en envoyant des mails sans se conformer aux standards, ça ne peut 
que mal se passer.


C'est un peu comme se connecter sur un IX sans configurer les ROAs : ça 
fonctionne jusqu'au jour où ça passe plus.


Bientôt dans vos salles : "je n'ai positionné mes enregistrements MX et 
je ne reçois pas de mail, c'pas normal !"


Julien


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

Re: [FRnOG] [TECH] ToR ou MoR

[Julien Escario]

Ah oui, ok, tu vas vraiment loin dans l'idée de faire 'bien les choses' 
en fait ;-)


Nos 7050 en mesuré consomment environ 80W une fois le boot terminé. Si 
tu aspires bien l'air côté cold corridor pour le souffler côté chaud, le 
flux est dans le bon sens. Perso, je ne pense pas que les 40 ou 50cm 
entre la facade de la baie et l'arrière des Arista pose un soucis 
quelconque. Surtout si tu as des serveurs rackés en face avant sur l'U 
au dessus ou au dessous; ils feront, partiellement du moins, office de 
guide d'air, même si tu as deux 7050 au dessus l'un de l'autre. Bon, ok, 
il y a un peu de perte de charge par les rails, sur le côté.


C'est d'ailleurs une bonne raison pour ne laisser plein d'U vides dans 
tes baies ;-)


Et honnêtement, qu'un switch aspire de l'air à 22°C ou à 30°C, je ne 
pense pas que va change grand chose pour lui. Un serveur avec ces 
300/500W/1000W (!), à la rigueur. et encore.


Sauf erreur, il y a une légère surpression dans les cold corridor 
(combien ?), inhérente à la soufflerie forcée des clims. Même sans 
ventilos, l'air froid circulera toujours un peu dans les équipements.


On est dans le détail et j'avoue ma limite de compétence à ce stade. Il 
y a probablement sur la liste, des gestionnaires de DC qui pourront être 
beaucoup plus précis que moi.


En tout cas, un 'avaloir' d'air pour baie, je n'ai jamais vu et ça me 
paraît compliqué puisque cela dépend de la longueur de tes équipements 
et surtout de la distance entre les montants avant et arrière de la 
baie. Il faudrait quelque chose de rétractable pour s'adapter à une 
gamme de profondeur et ça créerait forcément des pertes de flux d'air 
puisque l’étanchéité me paraît difficile à obtenir dans ces conditions.


Julien


Le 21/02/2022 à 13:15, guilla...@vass.al a écrit :

Bonjour Julien,

Parti trop vite désolé..

Je ne l'ai en effet pas précisé mais il s'agit bien de switch
"back-to-front" qui aspirent donc bien l'air depuis le cold corridor.

Mon problème reste que si je veux "bien faire les choses" d'un point
de vue DC je suis censé coller la face arrière (qui contient les
ventillos) alignée avec les blank-pannel coté cold corridor.
 -> Sauf que les ports deviennent difficilement accessibles

Si je décide de ne pas le faire:
 - le switch va aspirer l'air depuis l'arrière qui est au final le 
milieu de la baie
 - je met la grouille dans le principe du cold corridor car j'enleve 
un blank-panel ce qui fait un passage directe froid -> chaud.


D'ou mon idée de "tunnel rallonge" pour prolonger l'arriere de mon 
swicth est amener la prise d'air dans l'alignement de la facade coté 
froid.


Pour etre plus concret, on est sur ce genre de switch (ventilos bleu 
donc): 
https://www.arista.com/assets/data/pdf/Datasheets/7050X3-Datasheet.pdf


Il y a des rails la dessus qui font que ca se rack comme un serveur au 
final avec une fixation a l'avant et a l'arrière de la baies sans 
porte-à-faux


Guillaume


Le 21.02.2022 12:39, Julien Escario a écrit :

Ton switch 'de base', que sa face avant soit alignée ou non avec
l'avant de la baie, aspire de l'air chaud puisqu'il a un airflow avant
(= côté chaud) -> arrière (cold corridor).

Déjà, les DC n'aiment pas ça du tout puisque tu injectes finalement de
l'air chaud vers le cold corridor = ça oblige la clim à compenser. Un
switch par ci par là, ce n'est pas méchant mais quand il commence à y
en avoir beaucoup, ça joue (c'est comme les auvergnats).

Raison pour laquelle on trouve de plus en plus de modèles dits
reverse-airflow : le switch aspire l'air par l'arrière et le rejette à
l'avant (ou le côté).

Dernière solution : des switchs sans ventilateurs : en bonus, tu es
quitte que les ventilos crament. Hors PoE, ça doit se trouver
maintenant avec l'amélioration des consos des chips.

Julien



Le 21/02/2022 à 12:23, guilla...@vass.al a écrit :

Bonjour,

Petite question bonus pour savoir ce que qui se fait de nos jour 
niveau ventilation quand le switch est placé à l’arrière de la baie 
avec les ports coté couloir chaud donc !


Historiquement nous avions des switchs presque aussi profonds que 
nos serveurs donc nous les "enfoncions" dans la baie pour que 
l’arrière du switch soit aligné avec les faces avant des serveurs 
coté froid et qu'il aspire donc un air bien frais.


Depuis le dernier renouvellement la profondeur des switch a bien 
diminué et avec ce mode de pose nous nous retrouvons a devoir 
plonger l'avant bras dans la baie pour atteindre les ports. Sans 
compter qu'il faut laisser plusieurs U au dessous et et dessous 
pour voir quelque chose et y passer les mains.


Certains d’entre vous sont-ils dans la même situation ? Avez-vous 
décidé au final de mettre la face avant du switch aligné avec les 
rails arrière de la baie quitte a laisser un trou béant sur la face 
froide et que le switch avale un peu ce qu'il peut niveau air ?


Utilisez-vous sinon ce genre de choses type "SwitchAir" ex: 
https://www.geis

Re: [FRnOG] [TECH] ToR ou MoR

[Julien Escario]

Ton switch 'de base', que sa face avant soit alignée ou non avec l'avant 
de la baie, aspire de l'air chaud puisqu'il a un airflow avant (= côté 
chaud) -> arrière (cold corridor).


Déjà, les DC n'aiment pas ça du tout puisque tu injectes finalement de 
l'air chaud vers le cold corridor = ça oblige la clim à compenser. Un 
switch par ci par là, ce n'est pas méchant mais quand il commence à y en 
avoir beaucoup, ça joue (c'est comme les auvergnats).


Raison pour laquelle on trouve de plus en plus de modèles dits 
reverse-airflow : le switch aspire l'air par l'arrière et le rejette à 
l'avant (ou le côté).


Dernière solution : des switchs sans ventilateurs : en bonus, tu es 
quitte que les ventilos crament. Hors PoE, ça doit se trouver maintenant 
avec l'amélioration des consos des chips.


Julien



Le 21/02/2022 à 12:23, guilla...@vass.al a écrit :

Bonjour,

Petite question bonus pour savoir ce que qui se fait de nos jour 
niveau ventilation quand le switch est placé à l’arrière de la baie 
avec les ports coté couloir chaud donc !


Historiquement nous avions des switchs presque aussi profonds que nos 
serveurs donc nous les "enfoncions" dans la baie pour que l’arrière du 
switch soit aligné avec les faces avant des serveurs coté froid et 
qu'il aspire donc un air bien frais.


Depuis le dernier renouvellement la profondeur des switch a bien 
diminué et avec ce mode de pose nous nous retrouvons a devoir plonger 
l'avant bras dans la baie pour atteindre les ports. Sans compter qu'il 
faut laisser plusieurs U au dessous et et dessous pour voir quelque 
chose et y passer les mains.


Certains d’entre vous sont-ils dans la même situation ? Avez-vous 
décidé au final de mettre la face avant du switch aligné avec les 
rails arrière de la baie quitte a laisser un trou béant sur la face 
froide et que le switch avale un peu ce qu'il peut niveau air ?


Utilisez-vous sinon ce genre de choses type "SwitchAir" ex: 
https://www.geistglobal.com/switch-air-unit/10643/sa2-002 ou avez vous 
une solution bien moins onéreuse pour une simple rallonge au final !



Guillaume



Le 21.02.2022 11:51, David Ponzone a écrit :

J’avoue que je me suis posé la même question.
Le $job de Cécile a peut-être des supers prix à proposer en colo :)

Merci à tous pour vos retours, il semble y avoir quand même une
préférence pour le MoR, et je pense que ça va devenir la mienne aussi.
Pour être précis, je pense que ça sera exactement à l’endroit où mes
PDU APC verticaux n’ont pas de prise, puisque de toute façon le switch
en étant monté à l’arrière a ses câbles d’alimentation qui font
back->front. Ca change pas grand chose d’aller chercher une prise un
peu plus haut ou un peu plus bas.
Alors que pour un serveur 1U, c’est plus disgracieux/hétérogène.

D’ailleurs, aucun constructeur de baie n’a eu l’idée d’avoir des PDU
verticaux fixés sur la face intérieure et au milieu des portes
latérales ?
Parce que le PDU vertical à l’arrière sur les côtés, ça bouffe quand
même un max de place, où on aimerait bien mettre du cable-management.
L’autre avantage c’est que ça éviterait les câbles d’alim qui font
back->front pour les équipements réseaux (même idée que pour le MoR,
ça ferait des câbles d’alim de longueurs plus standard et plus facile
à gérer/cacher).
Et pour les serveurs qui ont les 2 PS du même côté, c’est facile de
connecter le PS vers le PDU le plus proche avec un câble de 50cm, mais
généralement l’autre PS aurait besoin de 75cm pour connecter le PDU de
l’autre côté, ce qui n’est pas exactement standard.


Le 21 févr. 2022 à 11:34, Julien Escario  
a écrit :


Le 21/02/2022 à 09:27, Cécile MORANGE a écrit :

Hello !

At $job, on fait que du middle of rack, ça donne ça:
https://twitter.com/AtaxyaNetwork/status/1405074545980100610
https://twitter.com/AtaxyaNetwork/status/1408410014994386945


Très chouette mais pourquoi cette manie de laisser des U vides entre 
les équipements ? Vous les payez moitié prix vos baies ?


Un jour, on m'a rétorqué que c'était pour le refroidissement (dans 
un airflow front/back ...). J'ose espérer qu'il y ai une vraie 
raison ;-)


Julien


---
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/


--
*Julien Escario*
Technicien Informatique

julien.esca...@altinea.fr
Tel direct : 03 74 39 10 21
Support : 09 70 75 44 25

Logo Altinea
*Conseils & Infrastructures
Informatiques*

Accueil : 03 74 39 10 20
9 Rue du faubourg 39570 Nogna
*www.altinea.fr <https://www.altinea.fr>*


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

Re: [FRnOG] [TECH] ToR ou MoR

[Julien Escario]

Le 21/02/2022 à 09:27, Cécile MORANGE a écrit :

Hello !

At $job, on fait que du middle of rack, ça donne ça:
https://twitter.com/AtaxyaNetwork/status/1405074545980100610
https://twitter.com/AtaxyaNetwork/status/1408410014994386945


Très chouette mais pourquoi cette manie de laisser des U vides entre les 
équipements ? Vous les payez moitié prix vos baies ?


Un jour, on m'a rétorqué que c'était pour le refroidissement (dans un 
airflow front/back ...). J'ose espérer qu'il y ai une vraie raison ;-)


Julien


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

Re: [FRnOG] [TECH] CCR2116-12G-4S+

[Julien Escario]

Le 09/12/2021 à 17:19, Arnaud FEIX a écrit :
> Pour rebondir sur les Mikrotik à vos mise à jour.
>
> https://thehackernews.com/2021/12/over-30-mikrotik-devices-found.html

Mais c'est pas encore et toujours le même truc qui ressort tous les 6
mois depuis 2019 ? Oui, Mikrotik a une vulnérabilité dans les versions
d'il y a trois ans, peut être pas la peine de tourner en boucle là
dessus, non ?

Au début, j'ai cru que c'était juste des journaleux qui aiment bien
faire peur mais je finis par me demander si ce n'est pas une vraie
campagne organisée.

Non pas que krotik soit au dessus de tout soupçon en matière de soft
(loin de là) mais des failles, y'en a partout tous les jours hein.

Julien



OpenPGP_signature
Description: OpenPGP digital signature

[FRnOG] [ALERT] Alphalink OpenVNO

[Julien Escario]

Bonjour,

Encore une qui va plaire à Bortzmoinsbien : un IPBX chez nous n'arrivait
plus à joindre sip3.openvno.net (un endpoint SIP d'alphalink).

Après quelques recherches, le domaine à tout simplement expiré ... plus
de résolution :

Registry Expiry Date: 2021-10-20T08:26:47Z

Domain Status: clientHold https://icann.org/epp#clientHold

J'ai cru comprendre qu'il y avait plusieurs personnes passant leur voix
par chez eux sur la liste, je me suis que ça ferait sûrement gagner du
temps de debug à plusieurs co-listiers.

Et si quelqu'un a deux secondes pour confirmer mon diag, je prends.

https://atlas.ripe.net/measurements/32564346/#probes

Trop de NXDOMAIN pour être honnête.

Julien




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] Re: [ALERT] OVH mort ?

[Julien Escario]

Le 13/10/2021 à 09:55, Stephane Bortzmeyer a écrit :
> On Wed, Oct 13, 2021 at 09:31:58AM +0200,
>  David Ponzone  wrote 
>  a message of 37 lines which said:
>
>> Pareil ici, j’ai leurs annonces sur Equinix-IX, mais aucun ping ou 
>> traceroute ne passe, aucun HTTP ne répond, pas même le DNS.
> Uniquement IPv4. IPv6, après un court problème, est reparti presque
> tout de suite.

C'est confirmé (si mon mail à la liste veut bien arriver dans un délai
raisonnable).

Octave a tweeté puis supprimé une erreur de copier/coller :

d2> ... route-map ipv

d2> 4

J'imagine que le routeur n'a pas trop su quoi en faire du 4 tout seul.

Julien


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

Re: [FRnOG] [ALERT] Re: Gros problème OVH ?

[Julien Escario]

Le 13/10/2021 à 09:32, Stephane Bortzmeyer a écrit :
> On Wed, Oct 13, 2021 at 09:29:28AM +0200,
>  Stephane Bortzmeyer  wrote 
>  a message of 3 lines which said:
>
>> Tout leur réseau semble très perturbé.
> Ça semble en train de repartir.

Alors, je dirais plutôt que c'est IP legacy qui est down, alors que l'IP
de ce siècle fonctionne :

$ host dns10.ovh.net
dns10.ovh.net has address 213.251.188.129
dns10.ovh.net has IPv6 address 2001:41d0:1:4a81::1

Ping OK sur l'IPv6 alors que l'IPv4 ne répond pas, un mtr s'arrête juste
avant leur AS.

C'est basique comme test, il faudrait un guru RIPE Atlas pour être
certain du diag de fortune ;-)

Mon pronostic : ils ont décidé de basculer en IPv6-only pour fêter leur
entrée en bourse. La voilà notre killer-app pour faire avancer le
déploiement.

Julien




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [ALERT] OVH mort ?

[Julien Escario]

Il y a un truc qui m'étonne : ici ovh.com s'affiche tout de même.

Je me demande bien ce qu'il peut se passer puisque l'AS16276 semble, au
moins partiellement, joignable.

Julien

Le 13/10/2021 à 09:30, Philippe ASTIER via frnog a écrit :
> 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]<http://www.ipconnect.fr/>
>>
>> Olivier Varenne
>> Co-gérant, Commercial & Développeur
>> T +33 (0)4 27 04 40 00 | ipconnect.fr<http://www.ipconnect.fr/>
>>
>> Suivez-nous !
>> [picto-twitter]<https://twitter.com/ip_connectweets>[picto-youtube]<https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>[picto-linkedin]<https://www.linkedin.com/company/20541473/admin/>
>> [cid:image005.jpg@01D7C014.42678B40]<http://www.ipconnect.fr/>
>>
>>
>> -------
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
-- 
*Julien Escario*
Technicien Informatique

julien.esca...@altinea.fr
Tel direct : 03 74 39 10 21
Support : 09 70 75 44 25

Logo Altinea
*Conseils & Infrastructures
Informatiques*

Accueil : 03 74 39 10 20
9 Rue du faubourg 39570 Nogna
*www.altinea.fr <https://www.altinea.fr>*




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] RE: [TECH] ATS + UPS = cdhsjkezlkezllksq

[Julien Escario]

Le 07/10/2021 à 15:40, Pierre Colombier via frnog a écrit :
> Petite reflexion connexe au sujet propos des onduleurs et autres alims
> redondées.
>
> [...]
> Dès lors, pourquoi s'emmerder avec des systèmes qui travaillent en
> courant alternatif qui sont à la fois chers et compliqués à mélanger.
>
> Il y a le problème des onduleurs, il y a le problème de la synchro des
> groupes electrogènes, des temps de commutations etc...
>
> ça ne serait pas carrément plus simple de faire la distribution (et
> surtout le mélange des sources) avec du courant continu ?


Il fût une époque où on trouvait pas mal d'équipements en 48V DC avec la
possibilité de se faire livrer ça dans les baies. Il reste des reliques
(une salle complète dans l'ex-lambdanet Cogent Dijon au moins).

48V, ça fait 4 éléments 12V en série et c'est en dessous de la limite
qui impose des habilitations spécifiques (choc électrique) dans pas mal
de pays.

Le problème du 48V DC, c'est que ... ce n'est pas du 230 ou 110V : je ne
voudrais pas dire d'ânerie mais c'était devenu vraiment compliqué pour
les constructeurs de maintenir du matos de série avec des alims 48V.
Tout était en doublon, même si le design d'une alim, c'est clairement un
truc automatique dans n'importe quel CAD.

Je pense que le soucis tient plus dans les stocks à maintenir : deux
fois moins de référence, c'est deux fois moins de stock à gérer, point
barre.

Autre 'petit' inconvénient : 3kVA de base par baie en 48V, ça fait déjà
64A à faire arriver (x2) donc facilement du 16mm2 voire du 20mm2 alors
que c'est du 2,5mm2 en 230V. Et le cuivre, ça coûte cher.

Julien



OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] Choix d'AP WIFI

[Julien Escario]

Le 30/09/2021 à 17:40, Nicolas Vuillermet a écrit :
> Hello,
>
> De notre côté, nous regardons chez Ruckus avec le R750 / R850.
>
> Ce qui fait chavirer notre cœur est la possibilité de faire du 802.1 sur un 
> SSID (avec un joli radius derrière) et du DPSK pour les périphériques 
> éc̵l̵a̵t̵és̵ modestes ainsi que les invités (avec tout autant un joli radius 
> derrière qui te permet de coller le backend que tu veux ou une api rest, 
> permettant de balancer un tunnel ID transformé en vlan côté AP).
>
> Enfin, une borne Wi-Fi 6 avec un uplink seulement gigabit, ça me semble assez 
> aberrant. (Oublions unifi, Mikrotik a déjà perdu la lice à ce stade..)
>
> Côté controller, où devrais-je plutôt parler de manager, il y a Ruckus 
> Unleashed embarqué sur les AP avec élection du master, ou plus casual du 
> manager onpremise voir en virtu avec SmartZone.
>
> Tout cela d’après mes recherches, on va sûrement se diriger vers cette 
> direction.
>
> Ah, cahier des charges aussi, ne pas se taper des frais récurrents et ne pas 
> être forcé à un accès Claude permanent parce que bon, faut pas qu’il mette 
> ses sales mains partout non plus.

Tu vas les prendre les frais récurrents mais de manière plus insidieuse
: Ruckus va te passer les bornes en deprecated un beau matin, impossible
de mettre à jour le contrôleur sans remplacer tes bornes parce qu'elles
n'auront pas le firmware version Y nécessaire pour aller avec le
contrôleur version X. Et impossible de rajouter une borne parce qu'elle
est déjà en version Z incompatible avec ton contrôleur en version V.

Après, je ne dis pas qu'ils sont les seuls. C'est même devenu la norme
(cf Ubnt). Ce sont les constructeurs qui décident de la durée de vie du
matériel en fonction de l'évolution de leur EBITDA.

Julien




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] Black Thursday

[Julien Escario]

Le 29/09/2021 à 17:22, Wallace a écrit :
> On encourage les gens à garder leur matériel plus longtemps mais on
> leur coupe un des usages si ce n'est le majeur de leurs appareils. Pas
> de web, pas d'api pour les store, ...
>
> A mon avis va y a voir des appels dans les hotlines des FAI, ça marche
> pas j'arrive plus à aller sur Internet, moi j'ai rien changé ...

Meuh non, tout le monde sait que Internet = Facebook. Vu qu'ils
n'utilisent pas Let's Encrypt (sans vérifier, je l'ai bloqué niveau DNS
ici), ça va passer crème.

Qu'est-ce qu'on va rigoler vendredi ! Si *en plus* y'a d'la Chouffe,
alors là ...

Julien



OpenPGP_signature
Description: OpenPGP digital signature

[FRnOG] [TECH] DNSSEC et puis s'en va

[Julien Escario]

Bonsoir,

Un peu tard pour causer technique comme ça mais on vient d'avoir un
soucis de résolution sur mxa.mailgun.org et mxb.mailgun.org.

Vérification faite, nos résolveurs avaient une DS key en cache pour la
zone mailgun.org :

$ dig @resolveur2 mailgun.org DS

mailgun.org.        80164    IN    DS    49611 8 2
28F2F10427480AC6FB98D7544D61FE8D866EB5FB33688BC7C3CB8DC6 5D39C916

Mais cette DS ne semble visible nul par ailleurs.

Mon intuition étant qu'ils ont activé DNSSEC 'quelque part', nos
résolveurs ont attrapé l'info puis il y a eu un rollback.

Nos résolveurs étant configurés pour la validation DNSSEC, c'était
évidemment cassé.

Une idée de la façon dont je peux valider cette hypothèse ? (juste pour
me coucher moins bête). A priori, j'ai 22h pour trouver, ensuite le
cache n'existera plus.

J'ai une trace de mon pdns recursor sur une requête que je ne suis pas
certain de savoir analyser correctement. Je peux envoyer en privé si besoin.

Merci,

Julien


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

Re: [FRnOG] [TECH] Geolocalisation IP sur les plateformes de streaming

[Julien Escario]

Le 24/08/2021 à 14:58, Julien Escario a écrit :
> Le 24/08/2021 à 13:29, Olivier FONTÈS a écrit :
>> Nous avons rencontré ce soucis de black list avec les connexions
>> occitanet il y a un peu plus de deux ans. 
>>
>> Nous avons contacté le support de netflix en utilisant un des comptes de
>> nos clients et ils ont retiré notre /22 ipv4 et notre /29 ipv6 de leur
>> blacklist en 48 h. 
>>
>> Si ça peut aider j'ai ptet encore le mail du support tech.
> Merci, j'ai tenté la procédure ce matin, on va voir si ils retirent tout
> le /24 ou juste l'IP.
>
> J'attends de voir le résultat mais en dernier recours, je prends
> volontiers l'adresse d'un tech ou service en off pour plus d'efficacité
> (et éviter la batterie de questions sans aucun rapport avec le problème).
>
> Julien

Donc si cela peut servir à quelqu'un dans le futur : ~24h après, je
constate que Netflix a carrément whitelisté le /22 entier (mon jumphost
avec un beau reverse en 'vpn' passe aussi) alors que je ne demandais que
le /24.

J'imagine qu'à leur échelle, ça ne fait pas une grande différence.

J'attends le retour de mon client pour savoir si FranceTV a suivi, ce
qui confirmerait qu'il y a une liste commune d'une manière ou d'une autre.

Julien



OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] Geolocalisation IP sur les plateformes de streaming

[Julien Escario]

Le 25/08/2021 à 09:10, Vincent Bernat a écrit :
>  ❦ 24 August 2021 10:59 +02, Julien Escario:
>
>> Est-ce qu'il y a ici des gens qui savent quelle service utilisent les
>> plateformes de streaming pour déterminer si une IP est utilisée en tant
>> que VPN/Proxy ou a accès à un catalogue ?
>>
>> Depuis la mi-juillet, nous avons identifié au moins deux plateformes
>> (Netflix et FranceTV) qui interdisent l'accès à des IPs dans un subnet
>> chez nous (185.123.87.0/24) et je ne parviens pas à en connaître la
>> raison exacte.
>>
>> RIPE DB propre (obviously) et Maxmind nous situe bien en France. J'avoue
>> que je ne vois pas trop quoi d'autre modifier pour qu'ils remettent le
>> sub dans la bonne catégorie.
> Il y a plein de bases différentes et les content providers sont plutôt
> discrets pour te dire quelle base ils utilisent. Il y a quelques indices
> sur comment faire corriger la base de chaque provider ici (plutôt
> orienté US) :
>
> https://thebrotherswisp.com/index.php/geo-and-vpn/

Cette page est une sacré mine d'infos !

Je constate par exemple que ipinfo.io rajoute 'vpn: true' à toutes les
IPs dans le range qui m’intéresse. Plus qu'à trouver comment corriger ça.

Merci !

Julien




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] Geolocalisation IP sur les plateformes de streaming

[Julien Escario]

Le 24/08/2021 à 11:51, Vincent Habchi a écrit :
>> Les IPs de OVH et Scaleway sont blacklistés aussi ; par exemple.
> Oui, j’avais oublié ça.
>
> Il faut dire qu’il est facile de louer un serveur pour quelques euros par 
> mois et installer un VPN genre strongswan dessus.
>
> V.

Ce que je ne comprends pas dans tout ça, c'est pourquoi est-ce qu'ils ne
se basent pas sur l'adresse de facturation du compte, en tout cas pour
Netflix : un compte est dans un pays et il a accès au catalogue, peu
importe d'où il se connecte.

Au lieu de ça, ils se font chier avec des pseudos listes d'IP par pays +
un système de réputation.

Julien




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] Geolocalisation IP sur les plateformes de streaming

[Julien Escario]

Le 24/08/2021 à 13:29, Olivier FONTÈS a écrit :
> Nous avons rencontré ce soucis de black list avec les connexions
> occitanet il y a un peu plus de deux ans. 
>
> Nous avons contacté le support de netflix en utilisant un des comptes de
> nos clients et ils ont retiré notre /22 ipv4 et notre /29 ipv6 de leur
> blacklist en 48 h. 
>
> Si ça peut aider j'ai ptet encore le mail du support tech.

Merci, j'ai tenté la procédure ce matin, on va voir si ils retirent tout
le /24 ou juste l'IP.

J'attends de voir le résultat mais en dernier recours, je prends
volontiers l'adresse d'un tech ou service en off pour plus d'efficacité
(et éviter la batterie de questions sans aucun rapport avec le problème).

Julien




OpenPGP_signature
Description: OpenPGP digital signature

[FRnOG] [TECH] Geolocalisation IP sur les plateformes de streaming

[Julien Escario]

Bonjour la liste,

Est-ce qu'il y a ici des gens qui savent quelle service utilisent les
plateformes de streaming pour déterminer si une IP est utilisée en tant
que VPN/Proxy ou a accès à un catalogue ?

Depuis la mi-juillet, nous avons identifié au moins deux plateformes
(Netflix et FranceTV) qui interdisent l'accès à des IPs dans un subnet
chez nous (185.123.87.0/24) et je ne parviens pas à en connaître la
raison exacte.

RIPE DB propre (obviously) et Maxmind nous situe bien en France. J'avoue
que je ne vois pas trop quoi d'autre modifier pour qu'ils remettent le
sub dans la bonne catégorie.

Rien de bien dramatique mais je commence à avoir 2/3 retours clients et
ce n'est pas agréable.

Merci pour vos lumières,

Julien




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] [BGP] [Cisco]

[Julien Escario]

Le 12/07/2021 à 20:25, David Ponzone a écrit :
> Mikrotik!

C'est faux : c'est supporté depuis belle lurette. Suffit de mettre l'IP
sans subnet comme IP et l'autre comme network.

La langue, la bouche, 7 fois, toussa.

Julien




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] Le prix des adresses IPv4

[Julien Escario]

Le 28/06/2021 à 18:49, Vincent Habchi a écrit :
> Hey,
>
>> Oh certainement pas l'état Américain ni l'ONU. L'ICANN serait probablement 
>> le choix le plus répandu, mais ne fait pas l’unanimité.
> Quels sont les autres ?
>
> Merci pour le point historique !
>
> Mais cette histoire de non-propriété est un peu problématique. 
Pas du tout en fait ;-) C'est très occidental de considérer que chaque
chose doit avoir un propriétaire.
> Qu’arriverait-il si quelqu’un se mettait à publier une route pour un segment 
> (disons, pour faire moins conflictuel, non attribué) sans l’autorisation du 
> régional correspondant, ou de l’ICANN ? Et défendait son bout de gras en 
> disant que, puisque les adresses sont, pour ainsi dire, res nullius, rien ne 
> l’empêche de s’en attribuer un morceau ?

Il faut faire un peu d'histoire là : Internet, c'est la bazar (dans le
sens 'la cathédrale et le bazar'). C'est un projet communautaire qui a
fonctionné. A posteriori, un certain nombre de choses se sont mises en
place politiquement : les RIRs, ICANN et une certaine reconnaissance par
l'ONU.

Mais dans les faits, ce n'est pas un législation qui dicte le
fonctionnement d'Internet : ce sont des communautés, ici regroupées sous
l'appellation RIPE et au niveau mondial sous les termes ICANN/IANA/IETF
pour les différents niveaux.

Tout ça est organisé selon un modèle documenté et tend à converger vers
un modèle, jusqu'au prochain retournement de table.

Si tu n'adhères pas aux règles de la communauté, tu dégages.

Pour n'importe quel juge, même à la CPI, c'est forcément hors-périmètre
d'intervention et il devrait se déclarer incompétent sur la question.

A ma connaissance, il n'existe aucune cours de justice ayant un mandat à
portée mondiale et reconnue par l'ensemble des états.

Bref, tout ça est fragile et stable à la fois. Ca semble un bon modèle
de coopération internationale même si il est complexe à comprendre. Il
fallait bien quelques geeks pour l'inventer ;-)

Le gros point de vulnérabilité de tout ça reste les intérêts financiers
qui n'existaient pas au départ et avec lesquels il faut maintenant
composer. Michel t'en dira plus à ce sujet.

Julien

P.S. : il me manque encore beaucoup d'éléments de compréhension et il
est probable que je me fasse étriller par les spécialistes sur les
raccourcis utilisés dans ce mail




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [MISC] Re: Donne baie informatique

[Julien Escario]

Laisse moi deviner : Cécile vient chercher la baie en métro ?

Le 24/06/2021 à 15:38, Mickael Hubert a écrit :
> Ça a été rapide, j'ai trouvé preneur ;)
> ++
>
> Le jeu. 24 juin 2021 à 15:10, Mickael Hubert  a écrit :
>
>> Bonjour à tous,
>> ma société déménage et donne une bien jolie baie info 42U, 19 pouces. Elle
>> est neuve, voici les photos: https://photos.app.goo.gl/68eDdSjv9Qiut3i96
>>
>> A venir chercher obligatoirement avant lundi 28 midi, dans le 8ème.
>> (Adresse précise fournie au premier qui ira la chercher ;) )
>>
>> Bonne journée
>>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] Jerikan : un système de gestion de configuration pour les équipes réseau

[Julien Escario]

Voilà qui est fort sympathique, merci !

Du coup, je rebondis non pas sur un mais sur deux threads récents :

* Est-ce que c'est du SDN ? (spoiler : je dirais oui, totalement)

* OVHCloud cherche du monde pour son NOC ;-)

Julien

Le 25/05/2021 à 14:57, Vincent Bernat a écrit :
> Hello !
>
> Nous avons publié (nous = l'équipe réseau de Blade/Shadow) notre outil
> interne de gestion de configuration orienté réseau. Cela comprend un
> soft qui génère des fichiers de configuration à partir d'une source de
> vérité et de templates, d'un playbook Ansible mais aussi de la
> configuration quasi-complète de nos datacenters de San Francisco et de
> Corée du Sud. Cela couvre la partie datacenter mais aussi la partie
> edge.
>
> https://vincent.bernat.ch/fr/blog/2021-reseau-jerikan-ansible
>
> Il me semble que c'est assez peu fréquent de trouver ce genre de choses
> et cela peut donc intéresser ceux qui se demandent comment configurer un
> routeur pour du transit et du peering (Junos ou IOS XR) ou comment faire
> le provisioning des switchs en datacenter.
>
> Nous publions ceci "tel quel" car notre société a été rachetée et
> l'infrastructure va être migrée chez OVHcloud. Les deux DC en question
> sont déjà éteints. Du coup, c'est une bonne occasion de pouvoir publier
> des vraies configurations qui ont tourné pour de vrai en production.


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

Re: [FRnOG] [TECH] Petite question Postfix

[Julien Escario]

Je sais bien qu'on est vendredi après-midi mais ta demande est quand
même sacrément confuse ...

Si tu veux une réponse, soit clair et précis. Encore plus sur cette
liste que sur beaucoup d'autres, ce sera apprécié et tu maximises ta
chance de réponse pertinente et donc utile.

En bref, soit tech.

Julien

Le 21/05/2021 à 16:16, Vincent Habchi a écrit :
> Ah, non, ce n’était pas ma question en fait. Petit imbroglio.
>
> Je repends :
>
> Christophe Baegert m’avait répondu par mail perso à mon premier message 
> quelque chose du genre : « dis toujours ce qui te chiffonne ». je lui ai donc 
> envoyé un mail avec mon souci, mail qui m’est revenu en pleine face avec 
> l’erreur de RDNS. Comme je ne pouvais pas lui faire part de cette erreur par 
> mail direct (lol), je l’ai postée sur la liste pour qu’il soit prévenu ! :)
>
> V.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [BIZ] Recherche IPv4 publique

[Julien Escario]

Le 18/05/2021 à 12:22, Hugo SIMANCAS a écrit :
> Bonjour,
>
> Mais si tu as déjà un /24 tu ne peux pas en avoir un second ...
>
> Hugo

Euh, si, en ouvrant un autre LIR ... C'était déjà possible avant la mise
en place de la waiting list mais pour des /22. A ce niveau, rien de
change, sauf l'allocation maximale.

Je sais, de source sûre, que certains membres de la liste ouvrent des
LIR à tout de bras. Le passage à un /24 a certes réduit l'intérêt de la
chose. C'est tout de même un peu de taf administratif (compter une
journée pour la première ouverte, 1/2 journée ensuite voir deux heures
quand on est habitué).

Julien


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

Re: [FRnOG] [BIZ] Recherche IPv4 publique

[Julien Escario]

Bonjour,

Le 18/05/2021 à 11:14, Johnnathan CHAN a écrit :
> Salut à tous,
>
> Je suis à la recherche d'adresse IPv4. Même si elle commence à se faire
> rare à cause de quelques entités qui gardent un grand nombre d'ip qui n'ont
> pas besoin...
>
> N'hésitez pas à me mp, si vous souhaitez les vendre ! :)

Cela fait plusieurs fois que je vois passer ce genre de demandes sur la
liste.

En plein RIPE meeting, je me demande ce qui pousse à passer par un
broker pour obtenir des IPs, en tout cas pour des /24.

La waiting list du RIPE actuelle est à zéro jour, ce qui signifie qu'en
ouvrant simplement un LIR, vous êtes garantis d'obtenir un /24 en
quelques jours (disons ~15). Sans compter le /29 v6 en bonus.

https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-waiting-list

Est-ce qu'un /24 acheté reviendra moins cher qu'un /24 attribué ?

A vos trolls, vous avez 4 heures,

Julien



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

Re: [FRnOG] [TECH] Panne SIP Free (Free et Centile)

[Julien Escario]

Le 22/04/2021 à 11:48, Emmanuel DECAEN a écrit :
> Le 22/04/2021 à 11:18, Raphael Mazelier a écrit :
>>
>> Le SIP over internet, over un truc qui fait du bricolage nat comme le
>> cgnat free, bon courage en effet. C'est bien pour cela que les
>> entreprises de Centrex fournissait l'accès internet ou exigeait un
>> accès vraiment neutre (ou mettais en place un VPN). 


Je ne suis pas un grand habitué du SIP/RTP mais par curiosité, pour
définir un peu mieux le problème : est-ce que le serveur Centile 'porte'
l'IP publique lui même ou est-ce qu'il est derrière une sorte de
reverse-nat ?

Et est-ce que vous avec un STUN ou TURN défini dans le provisionning ?
Ca pourrait peut être aider pour le nat-traversal ?

Julien




OpenPGP_signature
Description: OpenPGP digital signature

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

[Julien Escario]

Le 22/04/2021 à 09:52, David Ponzone a écrit :
>> Donc, il faut bien se faire à l'idée, déjà bien implantée, qu'on ne gagne 
>> plus d'argent sur la revente de matériels ou de services tiers, mais que 
>> l'on ne peut s'en tirer qu'en vendant notre propre valeur ajoutée derrière…
>
> Après, ça donne une leçon à certains acteurs de la distribution qui depuis 
> quelques années sont devenus des revendeurs à flux tendu plutôt que des 
> grossistes. Jamais de stock, forte dépendance envers le constructeur ou les 
> problèmes d’acheminement. Effectivement au final, autant acheter au 
> constructeur.

Ce constat se fait sur à peu près tout en informatique. Un constructeur,
passé une taille critique assez basse finalement, n'a pas beaucoup de
mal à monter une chaîne logistique vers le client final. Le site
ecommerce, c'est quasiment une commodité maintenant et ensuite c'est
surtout de la logistique, beaucoup de gens savent faire ça très bien.

On est en train d'assister à la disparition des 'grossistes'. Prédiction
: dans 10 ans, ce métier n'existe plus.

Etape 1 : Ils se sont eux mêmes tiré une balle dans le pied en sautant
sur la revente de logiciels en SaaS qui ne coûte rien et en délaissant
leur métier historique : acheter de gros volumes, stocker et dispatcher
ensuite. Le stock, ca coûte de l'argent et avec 4% de marge brute sur le
matos, ca n'interresse personne.

Etape 2 : Les éditeurs leur passe au dessus de la tête en vendant les
renouvellements en direct puisqu'ils ont les coordonnées du client,
pourquoi s'en priver.

Etape 3 : Les grossistes ne savent plus faire de logistique, n'ont plus
de stock.

Etape finale : une petite crise sur la pénurie de semi-conducteurs et le
métier peut tranquillement mourir.

C'est fou comme on ne le redira jamais assez : pas de valeur ajoutée
(ressentie par le client), pas de business.

Julien




OpenPGP_signature
Description: OpenPGP digital signature

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

[Julien Escario]

Le 20/04/2021 à 18:27, David Ponzone a écrit :
> De toute façon, qui a besoin de 1Gbps de BP en wifi….

Au hasard : les mêmes qui ont besoin de plus de 640ko de mémoire vive ?
(désolé, elle était trop tentante)

Julien


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

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

[Julien Escario]

Le 20/04/2021 à 22:45, merwan.lis...@gmail.com a écrit :
> Hello,
> On utilise uniquement du Unifi chez nos clients. Selon ta surface à couvrir 
> il faudra prévoir +/- d’AP, mais les UAC-AP-PRO fonctionnent très très bien 
> et couvent une sacrée distance. 
> A partir du moment où tu commence à mettre du Unifi, tu es piqué et tu 
> remplace ton réseau petit à petit avec leurs matos 

Moui, c'est vrai que c'est vraiment pas dégueu avec un contrôleur.

Par contre, leur politique d'EoL illisible ne simplifie pas vraiment les
choses. En gros, un matin, en mettant à jour, on t'annonce que dans 12
mois, toute une génération d'AP va passer EoL.

Perso, remplacer un AP qui fonctionne parfaitement parce qu'il ne fait
pas la dernière techno à la mode, ca me fait quand même bien chier, sans
compter qu'il faut l'annoncer au client.

Et quand tu achètes de l'Unifi, c'est en grande partie pour le
contrôleur, donc évitez les arguments du type : "mais ta borne
fonctionnera encore, c'est juste qu'elle ne sera plus supportée par le
contrôleur".

Oui, ça m'a bien gavé récemment...

Julien



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

Re: [FRnOG] [MISC] OVH + openstack SBG3 en carton ?

[Julien Escario]

Le 16/04/2021 à 18:18, x.r...@sipleo.com a écrit :
> Donc oui, OVH ça énerve un peu, beaucoup mais n'empêche qu'ils ne mentent pas 
> trop sur la marchandise non plus, non ?
> Et a un certain prix tu sais forcément ce que tu achètes ou pas lol

Ca fait 2/3 fois que je lis cet argument (rien à dire sur le reste) :
"c'est pas cher donc fallait comprendre que tu n'avais aucune garantie".

Ce que trouve fallacieux dans cet argument, c'est que le discours d'OVH
c'est justement : on fait de supers trucs, super garanties (qui se
souvient du SLA à 100%) à des prix défiants toute concurrence.

En partant de ce postulat, comment envoyer chier tous ces gens (allant
du mec dans un garage au DSI de grosse structure) qui se sont dit banco ?

Et navré de vous l'apprendre mais dans notre industrie, le même truc
peut sans problème prendre un /10 en tarif sans la moindre justification
en terme de SLA. Juste avec quelques bonnes idées, de la mutualisation
intelligente, etc ...

Après, sur la première proposition consistant à prendre des baies, des
serveurs, des liens et en faire un truc homogène avec du SLA 'à la papa'
(comprendre qu'on ne promet par la lune mais qu'on fait le maximum pour
l'atteindre), j'ai quand même bon espoir qu'on soit quelques-uns sur
cette liste à avoir fait ce choix. Je ne doute pas d'ailleurs que
Vincent croule sous les propales à cette heure.

Il faut aussi intégrer qu'en 10 ans, le SLA minimal 'acceptable' sur une
infra IT est quand même passé de 2 jours à 2 heures.

Allé, bon week-end (avec les chevaliers du Fiel)

Julien



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

Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Julien Escario]

Le 13/04/2021 à 13:33, Will van Gulik a écrit :
> Question bête (encore une ;)), est-ce qu'avoir ssh 8.2 pour le support
> u2f sur le bastion (uniquement) pourrait fonctionner si les serveurs 
> derrnière n'ont pas encore de ssh 8.2 ? Je suis dans un cas similaire, 
> j'aimerai faire du 2FA, probablement fido/u2f, mais je peux pas passer 
> tout mes hosts en ssh 8.2 . (vieux cisco, mikrotik, et autre variantes
> mignonnes) .
>
> Un avis ? (Spoiler : je ne suis pas très familier avec ssh-agent, etc) . 
>
> Will

Salut Will,

On est plus à une question bête près, hein.

J'aurais tendance à dire que oui tant que tu ne cherches pas à faire de
l'agent-forwarding (c'est à dire que ton client SSH sur le bastion a la
capacité de se connecter à l'agent sur ton poste au travers de la
session que tu as avec le bastion, c'est assez dangereux quand tu ne
maîtrises pas le serveur intermédiaire). Note : gpg-agent ne semble pas
supporter l'agent-forwarding (ou j'ai loupé un truc).

Dans ce cas, tu as bien du 2FA entre ton poste et le bastion mais plus
entre le bastion et les hôtes finaux/finals.

Je n'ai jamais joué avec les bastions, préférant me concentrer sur les
clés et le 2FA mais j'imagine que l'idée c'est que tu te connectes à une
machine qui stocke les clés utilisées pour se connecter sur les autres
serveurs ? (en verrouillant l'IP source de connexion à celle du bastion
uniquement).

Ceci dit, si c'est le cas, si ton bastion se fait pourrir, l'ensemble de
ton processus sécu est pawned non ?

Et Mikrotik, avec leur R soft de bulot, ne supporte toujours pas ni
les autorités SSH, ni les clés ECC (nist p384, ed25519). C'est moche
mais ils l'ont promis pour Ros7 (avec l'auto-génération d'éléphants roses).

Julien




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Julien Escario]

Le 13/04/2021 à 10:26, Mickael Hubert a écrit :
> Bonjour à tous,
> Actuellement pour prendre la main sur nos serveurs (SSH), nous nous
> connectons à des accès VPN, il y a X profils (Ex: admin, développeurs, etc
> ..) et chaque profil n'a accès qu'à ce qu'il a besoin.
> Mais dans le cadre de notre compliance PCI-DSS, il nous manque 2 points à
> valider, l'un d'eux est la mise en place du 2FA sur nos accès SSH
> justement.
> [...]
> Peut-être du 2FA en hard (avec une clé)...

Alors, écoute, clairement, un yubikey en guise de 2FA, ca fonctionne
vraiment très bien. Nous n'avons pas de bastion ici encore mais toutes
les sessions SSH sont basées sur clé SSH privée exportée depuis
l'identité GnuPG de la yubikey (gpg-agent) + certificat SSH pour éviter
de devoir gérer une liste de clé SSH (le bastion rempli déjà ce rôle du
coup).

Si toutes tes machines sont parfaitement à jour, tu peux aussi partir
sur ed25519_sk. Je n'ai pas beaucoup jouer avec parce que OpenSSH 8+
obligatoire et honnêtement, on en est pas encore là. Ca évite de se
coller la partie GnuPG qui est assez mal documentée et même parfois
bugguée (spoiler : ne faites pas de ed25519 avec GnuPG).

J'ai écrit un bout d'exemple de conf rapide pour le support Yubikey à
l'époque, c'est toujours en ligne :
https://gitlab.altinea.fr/altinea/install-scripts/src/branch/master/ssh/yubibug.md

Attention, je ne garantis pas que ça va rester encore des mois en ligne ça.

Julien




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Julien Escario]

Le 08/04/2021 à 16:48, Michel Py via frnog a écrit :
>> l...@51514.fr a écrit :
>> Pour les bons, il y aura toujours curl.
> Et ça sert à quoi ? pour configurer un machin sans certificat ?

Ca sert à tout curl : il y a deux jours, j'ai diagnostiqué un soucis de
certificat LDAPS sur un service avec (voir la liste des protocoles
supportés par curl).

Julien




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] Résolution DNS étrangement partielle

[Julien Escario]

Le 23/03/2021 à 18:21, David Ponzone a écrit :
>
> Ah ça, le DNS qui répond qu’aux requêtes A, j’avais jamais vu….
> Keyyo semble subir l’effet On-a-été-racheté-par-Bouygues-On-se-tire.
> D’autres ont connu/connaissent le même sort en ce moment.
>
> Julien, si tu fais un reverse sur l’IP, tu
> trouves prx13.sip.phonesystems.net
> , tu peux ptet utiliser ça ? :

J'avais vu ça oui mais si l'idée est bonne, ce n'est pas comme si
j'avais la main sur le template de provisionning des téléphones ...

Merci pour vos analyses (encore un bigup à Bortz). Le plus triste dans
l'histoire c'est que ça va se finir avec soit un résolveur publique (un
quadX), soit avec une entrée statique dans le resolveur local.

Ce qui est, dans un cas comme dans l'autre, une mauvaise pratique mais
hors de question que je dégrade la qualité de mes résolveurs en
supprimant le qname-min.

La prochaine fois, on va me demander de virer la validation DNSSEC.

Bonne journée,

Julien




OpenPGP_signature
Description: OpenPGP digital signature

[FRnOG] [TECH] Résolution DNS étrangement partielle

[Julien Escario]

Bonjour,

Aujourd'hui, je tombe sur un problème chez un client qui utilise de la
VoIP Keyyo.

Après un peu de debug, on se rend compte que la résolution de
7472.lb.keyyo.net ne fonctionne pas sur nos résolveurs (SERVAIL).

Et j'avoue avoir un peu de mal à comprendre si c'est chez nous ou chez
eux. J'ai tenté Atlas mais je dois mal l'utiliser.

Ca : https://www.whatsmydns.net/#NS/lb.keyyo.net m'en dit déjà un peu plus.

Si je résume : DNS Chez Gandi, délégation de la zone vers
|lb-ns[1..4].keyyo.net|

|Rien de choquant si ce n'est que la délégation n'a pas l'air de passer
partout.|

|Ca peut être beaucoup de choses, y compris une sorte de GSLB qui
filterait par country-code par exemple.|

|J'ai tout de même ceci : https://atlas.ripe.net/measurements/29354619/.
On y voit quelques SERVFAIL mais des masses.|

|Une idée du test probant que je pourrais réaliser ?
|

|Merci !|

|Julien
|



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

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

[Julien Escario]

Le 18/03/2021 à 10:30, Stéphane Rivière a écrit :
>> Un NAS-HA, forcément, c’est sur un site, faut pas rêver. 
> C'est intéressant ce que tu dis. Je le croyais aussi.
>
> Avec la techno qu'on développe en interne (qui n'est que la synthèse des
> possibilités réunies de xen linux lvm drbd avec de la glue logique pour
> résumer), on fait aujourd'hui 'NAS de pauvre' entre GRA et RBX (2ms
> entre, avec des serveurs NVMe qui poutrent et lien stable à 2Gbps).
>
> Bon, c'est pas du CEPH, hein, c'est un truc de pauvre. Mais qui marche.
>
> Voire même en triplette entre GRA RBX SBG (latence max 13ms) et sur SBG
> un serv avec disques mécas 8To raid 10 (pour des trucs moins sensibles à
> la perf mais triplement redondés). Et on triche pas coté vitesse puisque
> l'acquittement vient après l'écriture sur le disque pour privilégier la
> sûreté.

Ah, un peu de tech ! ;-)

Alors, même avec Ceph, y'a pas mal de possibilités avec rbd-mirror qui
fonctionne de manière asynchrone. Avec ça, la latence, tu t'en fous, il
faut juste que le lien puisse engranger le débit de tes écritures. Et ça
marche en 'two-way'.

Je n'ai pas encore testé mais en Octopus, tu peux aussi faire du mode
snapshot, qui revient, peu ou prou avec un ZFS send/receive (si j'ai
bien compris).

En version 'du pauvre', il est tout à fait possible de faire tourner un
cluster Ceph avec ... un seul nœud (un étant un nombre impair) +
rbd-mirror. Même avec un seul OSD pour avoir la couche CephFS, RBD,
export NFS, exporter prometheus et tout le reste du stack.

Tout ça implique 2/3 manips au moment du PRA (changement de sens de
synchro, passage en primaire, etc ...). Chez nous, on a choisit de
documenter ça plutôt que de faire de l'automatique mais chacun ces
préférences et son engagement de service.

Mais même avec une des deux solutions ci-dessus, on peut trouver des
use-cases où un delta de 30s voire de 13ms n'est pas acceptable.

Julien




OpenPGP_signature
Description: OpenPGP digital signature

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

[Julien Escario]

Le 18/03/2021 à 10:01, Philippe ASTIER a écrit :
> 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.

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 ?

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.

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.

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

>> 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.
Tu connais les contraintes de dispo de mon client et ce qu'il a lui-même
vendu à ses clients ?
>> 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. 
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 ;-)

Julien




OpenPGP_signature
Description: OpenPGP digital signature

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

[Julien Escario]

Bonjour,

Je vous lis depuis quelques jours en train de vous étriper sur la place
du curseur de responsabilité d'OVH.

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.

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 ...

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.

Si on avait pu parler à un tech OVH d'un level suffisant, il nous aurait
probablement expliqué où était le risque (et il est probable qu'on
l'aurait mis de côté vu ce qu'il y avait par ailleurs) mais voilà, c'est
du low-cost et le tech, on y a pas accès parce que le marketing a
verrouillé la communication sur ces questions.

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.

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.

Julien

Le 18/03/2021 à 09:05, Stéphane Rivière a écrit :
>> Heureusement que tu n’as pas parié en 2017 après le black-out électrique et 
>> la promesse du démantèlement des dc containers. 
> OVH a doublé comme prévu son alim sur SBG, plusieurs M€ d'investissement
> et les conteneurs, ça se déménage en claquant des doigts ? Les permis de
> construire, le pognon, les thunes quoi, facile, j'achète, j'achète :)))
>
> OVH est en train de finaliser SBG5 (physique), certainement pour migrer
> SBG1 et SBG4 et ensuite "faire de la place" pour un SBG6 (physique).
>
> Bon, ça ne va pas assez vite pour toi... Monsieur pressé :)
>
-- 
*Julien Escario*
Technicien Informatique

julien.esca...@altinea.fr
Tel direct : 03 74 39 10 21
Support : 09 70 75 44 25

Logo Altinea
*Conseils & Infrastructures
Informatiques*

Accueil : 03 74 39 10 20
9 Rue du faubourg 39570 Nogna
*www.altinea.fr <https://www.altinea.fr>*




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] Subnet ip publique sur LAN

[Julien Escario]

Alors, pour la blague, dans le coin, on passe derrière une boite (qui a
fait faillite) qui adorait numéroter avec des subnets exotiques, comme
si ils avaient lu la RFC1918 de haut en bas mais pas de droite à gauche.

On a plein de 192.10.0.0/24, des 172.168.0.0/24.

On a même une grosse boite nationale, gérée en fédération de fédérations
qui a fait monter un réseau MPLS national et qui route dedans les subs
192.174.0.0/24 et suivants.

Ca donne une jolie table de routage en sortie du LAN :

192.178.253.0/24
192.178.254.0/24

etc. Avec des /28 au milieu sinon c'était trop simple.

Bref, les techs de base ont une fâcheuse tendance à s’asseoir sur
RFC1918 et suivants. J'ai même dû couper des doigts à des petits
nouveaux en interne.

Ah, et pour info, tous les profs de BTS info ici enseignent l'adressage
par classe. Je trimballe un document tout prêt expliquant l'état de
l'art quand je vais en RDV de suivi de mes alternants.

Sinon, vous en êtes où du déploiement IPv6, RPKI et DNSSEC/DANE ?

Julien

Le 16/03/2021 à 14:42, Jerome SCHEVINGT a écrit :
>
> Bonjour,
>
> Cela m'est arrivé plusieurs fois chez des clients sans trop de soucis.
>
> Notamment parce qu'a une époque, il y avait dans les docs IBM des
> exemples
> avec des IP de leur plage, et les premiers admin réseau en herbe
> voyaient sur la doc tel plage
> et bin ils mettaient la même sur leur réseau 
>
> a+
> Jérôme
>
> Le 16/03/2021 à 11:16, Richard MATOS a écrit :
>> Salut la liste,
>>
>> J'ai un client qui utilise un plage d'adresse ip publique sur son LAN,
>> est-ce que certains parmi vous ont rencontré ce cas de figure ?
>> Si oui quelle solution avez-vous implémenté?
>>
>> Merci
>>
>>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
-- 
*Julien Escario*
Technicien Informatique

julien.esca...@altinea.fr
Tel direct : 03 74 39 10 21
Support : 09 70 75 44 25

Logo Altinea
*Conseils & Infrastructures
Informatiques*

Accueil : 03 74 39 10 20
9 Rue du faubourg 39570 Nogna
*www.altinea.fr <https://www.altinea.fr>*



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

Re: [FRnOG] [TECH] Passerelle de filtrage de mails à base d'IA ?

[Julien Escario]

Le 03/03/2021 à 08:42, Mickael Monsieur a écrit :
> Proxmox Mail Gateway. Toutes des briques open source connues avec un GUI open 
> source et un support entreprise possible. 
>
> Utilisation depuis très longtemps, très satisfait.
>
> J’ai longtemps maintenu des vm avec postfix, mailwatch/mailscanner, s-a, 
> amavis/clamav, etc, pour 10x plus de travail et un résultat moindre. 

On est également en cours de test là dessus pour se tirer de chez
SpamExperts qui a rendu de bons services mais s'est violemment dégradé
depuis la rachat par ... SolarWinds.

Il y a quelques trucs qui m'ont déjà gêné quand même et j'ai dû
surcharger un template pour que le postfix gère le TLS proprement (aka
sans TLS1.0). Un petit menu permettant de configurer les versions et les
ciphers de TLS ne serait pas du luxe.

Mais mon expérience avec PVE (Proxmox Virtual Environnement) montre
qu'avec un abonnement (quasiment obligatoire pour une offre à
destination de clients finaux), on arrive à leur faire ajouter les
fonctionnalités qui manquent.

On peut même proposer ces propres patchs parce que ça reste de
l'open-source à la base : https://git.proxmox.com/

PMG, c'est juste une interface propre pour manager la stack
Postfix/Clamav/SpamAssassin/WhatElse au final mais le reporting est
plutôt sympa.

Pour revenir à la question initiale : est-ce qu'un filtre Bayésien,
c'est de l'IA ? Vu ce que l'on vend comme de l'IA, j'aurais tendance à
dire que oui.

Julien



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

Re: [FRnOG] [TECH] RIPE & DNSSEC

[Julien Escario]

Le 25/02/2021 à 09:00, Julien Escario a écrit :
> Bonjour,
>
> Ayant un ARC ce matin avec le RIPE, j'avais envie de faire bonne
> impression en commençant à signer mes rDNS avec DNSSEC.
>
> J'ai donc activé DNSSEC sur la zone dans mes PowerDNS et j'ai créé des
> champs ds-rdata dans mon objet domain.
>
> C'était il y a environ 45 minutes et je n'ai toujours pas de DS records
> dans la zone parente pour le moment.
>
> Si quelqu'un s'est déjà amusé à faire ça, est-ce que c'est juste long à
> remonter ou est-ce que j'ai raté une étape dans le déploiement ?
>
> C'est la zone 212.146.45.in-addr.arpa, au cas où l'invocation d'un Bortz
> fonctionnerait ou que le sujet intéresserait quelqu'un d'autre.

Autant faire l'update de suite : j'avais juste, c'est simplement que ça
a mis environ 3 heures à remonter dans la zone parente.

Julien



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

[FRnOG] [TECH] RIPE & DNSSEC

[Julien Escario]

Bonjour,

Ayant un ARC ce matin avec le RIPE, j'avais envie de faire bonne
impression en commençant à signer mes rDNS avec DNSSEC.

J'ai donc activé DNSSEC sur la zone dans mes PowerDNS et j'ai créé des
champs ds-rdata dans mon objet domain.

C'était il y a environ 45 minutes et je n'ai toujours pas de DS records
dans la zone parente pour le moment.

Si quelqu'un s'est déjà amusé à faire ça, est-ce que c'est juste long à
remonter ou est-ce que j'ai raté une étape dans le déploiement ?

C'est la zone 212.146.45.in-addr.arpa, au cas où l'invocation d'un Bortz
fonctionnerait ou que le sujet intéresserait quelqu'un d'autre.

Merci !

Julien


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

Re: [FRnOG] [TECH] blacklist by orange business (only)

[Julien Escario]

Le 18/02/2021 à 20:56, Simon Bressier a écrit :
> alors là par contre je ne comprends pas pour l'instant pour les user
> unknown, je crée les adresses à la volée en db lors de la visite sur
> la home page et les user unknown que vous reportez ne sont en effet
> pas du tout créés en db, vous utilisez un navigateur particulier, des
> extensions qui flinguent les sessions ?
> Je vais creuser dans les jours qui viennent.

Pas forcément grand chose d'exotique : Firefox 85 en mode protection
stricte. Ublock Origin ou pas ne change rien.

Ca passe nickel sur le Brave (base Chromium) que j'ai à côté sur la même
machine (une Mint).

Julien



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

Re: [FRnOG] [TECH] blacklist by orange business (only)

[Julien Escario]

Je plussoie sur le prometteur mais je ne suis même allé aussi loin :

This is the mail system at host scanmy.email.
[...]
: User unknown

Ce n'était peut être pas la bonne liste sur laquelle faire de la pub, on va te 
trouver tous les bugs du truc ;-)

Bon courage,
Julien

Le 18/02/2021 à 19:10, David Ponzone a écrit :
> C’est joli et prometteur, mais ça marche pas (404 not found au bout de 15% 
> d’analyse) :)
>
>
>> Le 18 févr. 2021 à 19:02, Simon Bressier  a écrit :
>>
>> Au cazou ça aide quelques-uns ici, j’ai dev il y a quelques mois le service
>> https://scanmy.email pour de l’analyse de setup email et reputation de
>> contenu
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
-- 
*Julien Escario*
Technicien Informatique

julien.esca...@altinea.fr
Tel direct : 03 74 39 10 21
Support : 09 70 75 44 25

Logo Altinea
*Conseils & Infrastructures
Informatiques*

Accueil : 03 74 39 10 20
9 Rue du faubourg 39570 Nogna
*www.altinea.fr <https://www.altinea.fr>*


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

Re: [FRnOG] [TECH] Audit réseau (pat ou port mirroring)

[Julien Escario]

Le 17/02/2021 à 12:06, David Ponzone a écrit :
> Un PI, ça le ferait pas ?
>
Ca existe un raspi avec deux cartes réseau ?

Julien


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

Re: [FRnOG] [MISC] Outils pour surveillance ping

[Julien Escario]

Bonjour,

Je suis aussi intéressé par une piste vers un truc simple. Ca semble
trivial mais rarement prévu 'out of the box' dans les outils de supervision.

Pour le moment, je me contente de :

mtr-o "LSDR NBAW JMXI" -z -b -t -4 

Mais je n'ai pas de joli graph en fonction du temps avec ça, juste des
stats détaillées sur la période.

On pourrait prévoir un machin complexe en shell qui récupère simplement
la sortie d'un ping et place des points sur un graph (latence et loss ou
pas).

Merci,
Julien

Le 16/02/2021 à 09:29, Lucas Viallon a écrit :
> Bonjour,
>
> Comme tous le monde, nous devons de temps en temps placer une liaison en
> surveillence car nos clients on des "micro coupures".
>
> Le genre de micro coupure que quand vous testez vous ne voyez rien car il
> faut le faire sur 24 a 48h.
>
> Jusqu'ici on lance un ping sur une machine et on regarde 24h plus tard
> combien on a perdu de ping. Pas tres fiable et pratique.
>
> Notre supervision Centreon fait un test de quelques pings toutes les 5mn
> donc on ne peut pas voir.
>
> Quelqu'un sait si il y a un outils opensource style une interface web, on
> indique l'ip a surveiller, cela lance un ping permanent (ou qui ce
> renouvelle toutes les x minutes sans periode de blanc)  et ou l'on peut
> retrouver dans l'interface un mini compte rendu  ?
>
> merci
>
> -------
> Liste de diffusion du FRnOG
> http://www.frnog.org/
-- 
*Julien Escario*
Technicien Informatique

julien.esca...@altinea.fr
Tel direct : 03 74 39 10 21
Support : 09 70 75 44 25

Logo Altinea
*Conseils & Infrastructures
Informatiques*

Accueil : 03 74 39 10 20
9 Rue du faubourg 39570 Nogna
*www.altinea.fr <https://www.altinea.fr>*


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

Re: [FRnOG] [TECH] Problème Free xDSL pour joindre des services en Suisse

[Julien Escario]

Ah, oui, ca pique. Comme tu l'as dis, c'est de l'ICMP mais à ce stade de
loss, c'est probablement révélateur d'un vrai problème.

Prochaine étape du debug : des traceroute dans les deux sens pour voir
si il y des points communs/différences entre les chemins et voir si tu
as une asymétrie.

Tu parles de ton FAI : ça signifie que tu n'as pas la main sur ton
routage ? Si oui, il est clairement la clé de l'équation:  normalement,
c'est lui qui est à même de te guider voire de résoudre le problème.
Sans compter qu'il va avoir d'autres clients touchés (enfin, c'est une
affirmation plus litigieuse).

Une chose est sûre : je doute que tu aies beaucoup de retour de la part
des netops de Free ici (mais bon, bouteille à la mer, toussa).

Julien

Le 15/02/2021 à 16:14, greg a écrit :
> Sorry je m’exprime peut être mal. > > Changement de transitaire du côté de 
> notre FAI. > > Les clients ont
plus de 75% de packet loss en ICMP. Ok c’est de > l’ICMP. Mais du coup
les services en https ne fonctionnent pas. A > noter qu’hier tout était
au vert, ce matin à partir de 6h, plus de > services. > > Les sondes
Atlas sont quasi ok partout en France. > > Si on essaye de pinger une IP
Free depuis notre réseau : --- > 78.244.247.xx ping statistics --- 3414
packets transmitted, 753 > received, 77% packet loss, time 3427882ms rtt
min/avg/max/mdev = > 45.005/48.712/92.586/7.990 ms > > Un ami en fibre
Free sur Paris et un autre en fibre sur Annecy, ca > passe niquel. En
xDSL sur 74 et 01, KO > > >> On 15 Feb 2021, at 16:04, Julien Escario >>
 wrote: >> >> Je dirais même plus : c'est
quoi "n'arrivent pas à joindre" ? >> >> Le 15/02/2021 à 14:14, greg via
frnog a écrit : >>> Hello, >>> >>> Petite bouteille à la mer mais si
quelqu’un de chez Free pouvait >>> m’aider… >>> >>> Nous avons plusieurs
utilisateurs Free xDSL (pas en fibre) en >>> Haute-Savoie/Ain qui
n’arrivent pas à joindre des services >>> hébergé en Suisse. On a tenté
des bascules de fournisseurs de >>> notre côté mais rien à faire. >>>
>>> Si une âme charitable passe par la… >>> >>> Merci. Greg >>> >>>
--- Liste de diffusion du FRnOG >>>
http://www.frnog.org/ >> -- *Julien Escario* Technicien Informatique >>
>> julien.esca...@altinea.fr Tel direct : 03 74 39 10 21 Support : 09 >>
70 75 44 25 Logo Altinea *Conseils & Infrastructures >> Informatiques*
>> >> Accueil : 03 74 39 10 20 9 Rue du faubourg 39570 Nogna >>
*www.altinea.fr <https://www.altinea.fr>* >> >> >>
--- Liste de diffusion du FRnOG >>
http://www.frnog.org/ >


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

Re: [FRnOG] [TECH] Problème Free xDSL pour joindre des services en Suisse

[Julien Escario]

Je dirais même plus : c'est quoi "n'arrivent pas à joindre" ?

Le 15/02/2021 à 14:14, greg via frnog a écrit :
> Hello,
>
> Petite bouteille à la mer mais si quelqu’un de chez Free pouvait m’aider…
>
> Nous avons plusieurs utilisateurs Free xDSL (pas en fibre) en 
> Haute-Savoie/Ain qui n’arrivent pas à joindre des services hébergé en Suisse. 
> On a tenté des bascules de fournisseurs de notre côté mais rien à faire.
>
> Si une âme charitable passe par la…
>
> Merci.
> Greg
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
-- 
*Julien Escario*
Technicien Informatique

julien.esca...@altinea.fr
Tel direct : 03 74 39 10 21
Support : 09 70 75 44 25

Logo Altinea
*Conseils & Infrastructures
Informatiques*

Accueil : 03 74 39 10 20
9 Rue du faubourg 39570 Nogna
*www.altinea.fr <https://www.altinea.fr>*


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

Re: [FRnOG] [TECH] Google et les IX :)

[Julien Escario]

Bonjour,

Le 18/12/2020 à 07:21, David Ponzone a écrit :
> Amusant, réponse de Google à une demande de peering:
> 
> "Thank you for requesting Internet Exchange (IX) peering with Google.
>  
> IX Peering requests are currently paused as we improve our automation systems 
> to incorporate Internet Route Registry (IRR) based filtering into all IX BGP 
> sessions.
>  
> During this time Google prefixes remains reachable on route servers at IXes 
> which we are connected to. For a complete list of our global IX presence 
> please visit our PeeringDB entry at https://www.peeringdb.com/asn/15169 
> 
>  
> While we undergo our system improvements we request that you update you IRR 
> entries to ensure your prefixes will be accepted by our filters. »
> 
> Ca fait longtemps qu’ils répondent ça ou c’est depuis l’autre jour ? :)
> 
> David

J'ai dû avoir la même il y a bien 6 mois quand j'ai activé un nouveau
IX. Il y a ~2 ans, c'était passé nickel.
Pas très précis, mais ça borne un peu les choses.

Julien


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

Re: [FRnOG] [TECH] Prise électrique commandée par câble (USB ?) : genre de PDU mono-prise sans réseau

[Julien Escario]

Le 07/12/2020 à 17:34, Olivier Cochard-Labbé a écrit :
> On Mon, Dec 7, 2020 at 5:05 PM DUVERGIER Claude <
> frnog...@claude.duvergier.fr> wrote:
> 
>> Bonjour,
>>
>> Je recherche un produit (ou un bricolage offrant la même fonctionnalité)
>> pour pouvoir redémarrer électriquement un équipement assez simple
>> (modem/routeur de FAI) à distance : sans avoir à me déplacer sur place.
>>
> J'ai eu le même problème sur un lab avec du matos non IPMI (PC engines APU)
> et ma solution: 44€ le pack des 4 prises intelligentes «Smart Life»:
> https://www.amazon.fr/gp/product/B086C1RJCZ/ref=ppx_yo_dt_b_asin_title_o07_s00
> Il faut du wifi dans le labo, mais ensuite c'est «Alexa, reboot mon
> routeur» :-)
> 
> Olivier

Ah super, vivement les "Alexa, reboote les datacenter de la zone est, on
va tester le PRA". Ca va être magique ...

Julien


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

Re: [FRnOG] [MISC] Création ADSL problème de boucle locale

[Julien Escario]

Le 07/12/2020 à 09:20, l...@51514.fr a écrit :
> Bonjour,
> 
> Je dérive du sujet original mais pour la fibre, comment cela va se
> passer en cas de saturation ?
> 
> Est-ce que le déploiement voit très large ? Est-ce facile d'augmenter le
> nombre de livraison sur la boucle locale ? etc ???

A ma connaissance, c'est peu ou prou la même chose : il y a un
dimensionnement du PM (point de concentration ultra-local) et du NRO (où
sont posés les équipements actifs). Si ça a été mal évalué, il faut
changer ou rajouter des éléments de collecte et là, la galère commence.

On commence d'ailleurs à voir apparaître des jarretières coincées dans
les portes entre deux PM côte à côte. Ce n'est probablement pas un hasard.

Il me semble avoir lu des histoires de FO 'volée' par l'opérateur qui
débarque pour livrer son client (enfin, c'est le sous-traitant qui fait,
ça permet de faire traîner les choses dans un ping-pong de responsabilités).

Donc au fur et à mesure que les PM se remplissent, il est probable qu'on
retourne dans le même genre de situation.

Jusqu'à présent, il semblerait que la règle soit : un logement = une
paire mais j'ai aussi lu des annonces qui tendraient à permettre de
faire livrer deux FO dans un même logement en mixant GP et 'PRO'.

Mais les experts de la 'concurrence par les infras' de la liste pourront
probablement être plus précis que moi, notamment sur les différences
ZTD/ZMD.

Bonne journée,
Julien


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

Re: [FRnOG] [MISC] Brouilleur téléphones mobiles

[Julien Escario]

Le 07/12/2020 à 09:04, Michel KOENIG a écrit :
> Bonjour,
> 
> J'ai une demande de brouillage des téléphones mobiles dans une entreprise
> 
> Quelqu'un aurai un produit à me conseiller ?

Oui : ne pas le faire. C'est rigoureusement interdit par la loi à ma
connaissance.

https://www.anfr.fr/fr/controle-des-frequences/brouillages/les-brouilleurs-dondes/quest-ce-quun-brouilleur-radioelectrique/


Julien


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

Re: [FRnOG] [MISC] Création ADSL problème de boucle locale

[Julien Escario]

Le 05/12/2020 à 13:17, Daniel via frnog a écrit :
> Bonjour
[...]
> l'abonnement- avec gain de cause à la sortie. Par la suite j'ai appris
> qu'Orange -qui n'était pas mon opérateur- avait récupérer discrètement
> ma ligne Adsl au motif que je possédai 2 liens. No comment.

Tu cherches aussi : deux paires de cuivre dans un résidentiel non
collectif ? Holàlà, mon bon monsieur, vous avez vu le cours du cuivre ?

Pour compléter j'ai eu le cas récemment : MED dans un patelin, toutes
les maisons qui n'avaient pas d'abonnement ont été automatiquement
dépouillées de leurs livraison cuivre. Et le mieux : 2 maisons à livrer
dans la même rue = deux fois les frais de désaturation, une seule
opération de desat (il a suffit de faire traîner un peu la première
demande) qui consistait à tirer un câble de collecte sur 4 poteaux (mais
ils l'ont fait à la nacelle, propre).

Y'a pas d'petit profit qu'y disaient ...

Julien


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

Re: [FRnOG] [ALERT] Incident Alphalink

[Julien Escario]

Bonsoir,
Pareil ici : la terminaison des appels est H.S sur les trunks SIP.

Merci d'avoir alerté !

Julien

Le 04/11/2020 à 23:08, Daniel via frnog a écrit :
> Bonsoir. Je confirme, uniquement Alphalink en berne.
> 
> Le 04/11/2020 à 23:01, Anthony Frnog a écrit :
>> Bonsoir la liste
>>
>> Il semblerait qu'Alphalink soit HS depuis 22h45.
>>
>> Plus rien ne répond chez eux.
>>
>> S'agit-il d'un incident localisé que chez eux?
>>
>> Cdt
>> Anthony
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 


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

Re: [FRnOG] [TECH] Borne Wifi

[Julien Escario]

Le 15/10/2020 à 20:17, Stéphane Rivière a écrit :

Le 15/10/2020 à 20:09, Oliver varenne a écrit :

Sauf erreur de ma part, les fréquences ou tu as droit à du 60db ne sont de 
toute façon pas autorisée en France.


Franchement, 1KW en 5GHz, c'est soit de la démence, soit un radar
militaire à impulsion :>


Moui. Sauf à avoir à faire 300 bornes comme tu dis, je vois mal 
l'intérêt. Sans compter qu'à moins d'avoir des poteaux bien hauts au 
dessus des arbres et du relief local, ça permet surtout de générer un 
bon millier de signaux par rebonds qui finissent pas devenir compliqués 
à démêler du vrai signal direct.


Mais ne pas oublier que Michel est dans le pays où on fait les choses en 
grand ! Les maisons, les bagnoles, même les routeurs. Donc quand on peut 
balancer des W, on va pas se priver.


Julien


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

Re: [FRnOG] [TECH] Borne Wifi

[Julien Escario]

Le 15/10/2020 à 11:06, Oliver varenne a écrit :

Déjà, fait limiter au pays "France"


Bah, ca dépend beaucoup de l'endroit où tu te trouves. Ici, il faut 
sélectionner aussi la Suisse et l'Allemagne par exemple ;-)


Et choisir aussi la bande C, le reste ne vous intéresse pas (en wifi 
extérieur en tout cas, pas encore).


C'est un peu de boulot, oui. Si un spécialiste de la carto sait 
récupérer tout ça en opendata et générer un outil magique, ce serait 
chouette mais je n'ai pas trouvé et c'est très loin de mes compétences.


Julien


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

Re: [FRnOG] [TECH] Borne Wifi

[Julien Escario]

Le 15/10/2020 à 10:23, Oliver varenne a écrit :

Le changement de pays permet d'outrepasser la limite de 500mw sur la bande 5Ghz 
en émission extérieure, et envoyer 1W (voir plus)
Mais cela désactive aussi souvent le DFS qui est la pour protéger les stations 
radar météo.


Alors si on fait ça (et même si on le fait pas), le mieux, c'est encore 
d'aller voir les fréquences des radars à proximité ici :

https://www.eumetnet.eu/wp-content/themes/aeron-child/observations-programme/current-activities/opera/database/OPERA_Database/index.html

Et de se mettre sur une bande de fréquence qui ne risque pas de créer 
d'interférences.


Parce que même avec une PIRE à 1W en extérieur, c'est assez désagréable 
pour les météorologues. Sans compter qu'en cas de détection, les 
nouvelles normes pour le DFS font que votre liaison va être H.S. un bon 
petit moment (ça peut vite prendre une heure de retrouver un canal dispo 
en 5Ghz).


Julien


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

Re: [FRnOG] [MISC] DSAV Project: sérieux ou scam ?

[Julien Escario]

Le 13/10/2020 à 10:41, GUIOT Jean-Philippe a écrit :
> Idem par ici.
> 
> Si j'ai bien compris la faille, il ne "faut" pas autoriser les récursions 
> depuis ses propres IP externes/d'AS. Auquel cas, l'attaquant spoof tes IP 
> externes et utilise ton serveur en récursif ou en fonction de ta 
> configuration, accède à des noms de domaine potentiellement "internes". C'est 
> pas très clair en tout cas je trouve ^^

C'est un peu plus sournois que ça puisque chez nous, c'est clean : les
résolveurs ne répondent qu'à nos subnets.
En l’occurrence, ce n'est pas un soucis de resolveur ouvert mais un
soucis de protection contre les sources spoofées.

Ils ont pris du DNS parce que c'est un service UDP fréquemment
disponible (le spoofing TCP est nettement plus compliqué).

> Dommage qu'on ne puisse pas "tester" en live un éventuel fix ☹

+1. Par contre, ils me renvoient le même mail une seconde fois, ça
commence à faire lourd.

Julien

> --
> Jean-Philippe GUIOT
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de David 
> Ponzone
> Envoyé : mardi 13 octobre 2020 10:35
> À : Frnog misc 
> Objet : [FRnOG] [MISC] DSAV Project: sérieux ou scam ?
> 
> J’ai reçu un mail de DSAV Project (venant d'un labo d’une université US dans 
> l’Utah), qui me semble surprenant.
> D’autres ont reçu un mail de leur part affirmant avoir détecté une faille 
> n’existant à priori pas ?
> Je vais les contacter pour avoir la méthode et la trace.


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

Re: [FRnOG] [MISC] DSAV Project: sérieux ou scam ?

[Julien Escario]

Salut,
Même chose ici, ca ne semble pas un scam. Pour moi, ils ont testé de la
résolution DNS sur tous les UDP/53 trouvés sur le réseau en spoofant
l'adresse source, rien de plus.

J'ai quelques résultats intéressants en ce qui me concerne. J'aimerais
bien avoir leurs commandes pour valider des solutions correctives.

Donc si tu as des retours et que tu peux, n'hésites pas à partager.

Merci,
Julien

Le 13/10/2020 à 10:34, David Ponzone a écrit :
> J’ai reçu un mail de DSAV Project (venant d'un labo d’une université US dans 
> l’Utah), qui me semble surprenant.
> D’autres ont reçu un mail de leur part affirmant avoir détecté une faille 
> n’existant à priori pas ?
> Je vais les contacter pour avoir la méthode et la trace.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 


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

Re: [FRnOG] [MISC] Contact wholesale Bouygues

[Julien Escario]

Le 16/09/2020 à 10:06, Jean-Pierre Roussanidès via frnog a écrit :
> Bonjour,
> 
> 
> Quelqu'un pourrait me donner un contact chez Bouygues Wholesale ?

Bah je crois qu'on s'est posés la même question, je prends aussi ;-)

> Merci à vous
> 
> JP Roussanidès
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Julien Escario]

Le 08/05/2020 à 20:23, Damien DUJARDIN a écrit :
> Tu aurais du lire mieux (troll gratuit du vendredi)

Mais justifié ;-)

> Techniquement il utilise un bit réservé dans l'entête donc ça peut
> fonctionner.

Merci, tu viens de me faire gagner deux bonnes heures à comprendre
quelle bidouille il utilise.
C'est donc un bit flip.

Ce qui ne change rien au fait que c'est du vent mais la raison n'est
plus totalement technique.

Julien


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

Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Julien Escario]

Il faudrait peut être expliquer pourquoi sa proposition est une
aberration totale ?

Si j'ai bien compris, le monsieur propose de jouer sur la représentation
de l'IP dans un paquet. En changeant [0-255].[0-255].[0-255].[0-255] en
[0-65535].[0-65535].
Ce qui est une connerie abominable au niveau technique puisque dans un
paquet, il n'y a aucun point, uniquement |0-F]{8} donc c'est strictement
la même chose.

J'ai arrêté ma lecture à ce stade tellement j'ai trouvé ça à des années
lumières de la connaissance technique qu'il faut pour causer de ça. Si
même moi, avec mes quelques notions de réseau je comprends ça (tout en
ramant pas mal pour suivre les prez des RIPE Meeting), le mec n'a juste
rien à faire ni au RIPE, ni à proposer un draft.

Juste ou j'aurais dû lire mieux ?

Julien

Le 08/05/2020 à 19:44, Hugues Voiturier a écrit :
> Est-ce que c’est un troll ?
> 
> Dans le cas contraire, ce genre de propos est franchement indigne d’une ML 
> comme FRnOG…
>  
> Hugues
> AS57199 - AS50628
> 
>> On 8 May 2020, at 19:24, Bruno LEAL DE SOUSA  
>> wrote:
>>
>> Hello,
>>
>> Je ne connais pas ce fameux candidat mais au vu de la complexité d'adoption
>> de l'IPv6 et de l'attachement à l'IPv4, proposer ce type de solution est
>> intelligent et encourageant !
>>
>> A suivre...
>>
>> Bruno LEAL DE SOUSA
>> 06.01.23.45.96
>>
>> Le ven. 8 mai 2020 à 15:42, Christophe PLESSIS  a écrit :
>>
>>> Bonjour,
>>> Avez vous reçu cette information pour augmenter le nombre d’ipv4 ? Quel
>>> est votre avis ?
>>> A bon entendeur.
>>> Christophe
>>>
>>> De : Elad Cohen 
>>> Envoyé : vendredi 8 mai 2020 00:06
>>> À : contact 
>>> Objet : Message important concernant les élections du RIPE
>>>
>>> Bonjour,
>>>
>>> Je m'appelle Elad Cohen et je suis candidat au conseil d'administration du
>>> RIPE lors des prochaines élections, qui auront lieu le 13 de ce mois.
>>>
>>> J'ai créé une solution technique avec laquelle il y aura plus de 4 294 967
>>> 296 adresses IPv4 pour les 5 registres Internet régionaux, y compris le
>>> RIPE, vous pouvez en savoir plus à ce sujet ici :
>>>
>>> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003676.html
>>>
>>> Le problème « d'épuisement d'IPv4 » sera derrière nous et chaque membre
>>> RIPE recevra au moins un /21 d'adresses IPv4 gratuites si je suis élu.
>>> Personne d'autre ne mettra en œuvre ma solution technique, je vous demande
>>> votre vote en ligne. Sans votre vote en ligne à la prochaine assemblée
>>> générale du RIPE, ma solution technique ci-dessus ne sera pas mise en œuvre.
>>>
>>> Veuillez vous inscrire au vote en ligne pour les élections du RIPE en
>>> utilisant le lien suivant :
>>> https://www.ripe.net/s/gm-registration-may-2020
>>>
>>> Si vous rencontrez un problème pour vous inscrire au vote en ligne,
>>> veuillez envoyer un courrier électronique à a...@ripe.net>> a...@ripe.net>
>>>
>>> ---
>>>
>>> Outre la solution technique susmentionnée au problème de « l'épuisement de
>>> l'IPv4 », il existe deux autres solutions techniques que je m'efforcerai de
>>> mettre en œuvre si j'ai l'honneur d'être élu :
>>>
>>>
>>> Une solution technique au problème mondial du spam par courrier
>>> électronique :
>>>
>>> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003778.html
>>>
>>> Une solution technique au problème mondial de l'amplification de
>>> l'usurpation du DDoS :
>>>
>>> https://www.ripe.net/ripe/mail/archives/members-discuss/2020-April/003902.html
>>>
>>> ---
>>>
>>> Si vous votez pour moi et que je suis élu, je ferai en sorte que RIPE
>>> devienne :
>>>
>>> - Une organisation 100% transparente.
>>>
>>> - Une organisation centrée sur le LIR (il y aura un ANS de 24 heures pour
>>> chaque demande d'assistance, après quoi le membre du RIPE pourra évaluer la
>>> qualité du service reçu et marquer si la demande d'assistance a été résolue
>>> ou non, et si ce n'est pas le cas, l'assistance de niveau 2 recevra
>>> automatiquement la demande d'assistance). Chaque aspect du RIPE changera
>>> pour être centré sur le LIR et non sur la bureaucratie.
>>>
>>> Une organisation efficace en termes de dépenses de RIPE, je veillerai
>>> personnellement sur chaque dépense de RIPE afin de m'assurer que la RIPE
>>> soit une organisation efficace. Lorsque RIPE soit devenue une organisation
>>> efficace, les cotisations annuelles des membres de RIPE seront
>>> considérablement réduites.
>>>
>>> Je vous demande de vous inscrire pour le vote en ligne en utilisant le
>>> lien suivant :
>>> https://www.ripe.net/s/gm-registration-may-2020
>>>
>>> ---
>>>
>>> Le RIPE est géré par des personnes qui ne se soucient pas de vos intérêts,
>>> vous pouvez en voir l'exemple à travers les deux liens suivants :
>>>
>>>
>>> https://www.ripe.net/ripe/mail/archives/agm-nominations/2020-April/000692.html
>>>
>>> Dans ce lien ci-dessus, l'actuelle présidente du conseil d'administration
>>> du RIPE, Maria Hall, candidate à sa réélection, a soutenu la nomination de
>>> l'actuel président du conseil 

Re: [FRnOG] [MISC] Prochaine assemblée générale du RIPE - Vote pour le renouvellement de trois siège au board

[Julien Escario]

Le 01/05/2020 à 15:00, Denis Fondras a écrit :
>> Outre le mariole dont on a initialement parlé (Elad Cohen), qui est
>> candidat et promet monts et merveilles (ainsi que des trucs tres
>> farfelus techniquements), il y a également 6 candidats sur les treize
>> qui sont Iraniens, et sortis d'on ne sait trop où (une histoire de peur
>> de sanctions européeenes il me semble), assortis d'une représentation
>> assez forte de LIR iraniens qui voteront: Je ne suis pas expert en la
>> matière, mais je dirais ca ressemble un peu à une tentative de putsch.
>> Sauf que le risque, c'est que vu le nombre de candidats, les votes
>> soient bien dilués au final.
>>
> 
> En imaginant qu'ils gagnent les 3 sièges, quel est le risque ?
> Je fais confiance aux 4 membres restants pour sauvegarder les intérêt de TOUS
> les LIR de la zone en adoptant des positions consensuelles.

Peut être parce que déjà avec 3 sièges sur 7, ils pèseront lourd sur les
décisions et auront des responsabilités.

Et ensuite, parce que si ils suffit qu'ils fassent passer un 4ème
candidat au prochain renouvellement pour avoir la majorité.

Je n'ai pas compris leur logique mais c'est une autre culture. Il n'est
pas impossible, étant donné la façon dont les choses sont faites, que ce
soit organisé de manière étatique par le pays.

Vous voulez que les prochaines décisions concernant la gouvernance des
ressources (AS, IPv4, IPv6, Atlas, etc ...) soient prises de Téhéran ?

Note : si cela devait se produire, RIEN dans les status du RIPE (à ma
connaissance) ne permet de se prémunir contre la récupération du bureau
par un pays, tant que les décisions prises ensuite ne sont pas contre le
droit international (et plus particulièrement néérlandais).
Du coup, si c'est le scénarios qu'ils déroulent, on peut imaginer pas
mal de cas assez préoccupants.
Mais il y a nettement plus pertinent que moi sur le sujet et peut être
qu'on s'imagine un complot qui n'existe pas, chacun est juge.

Julien


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

Re: [FRnOG] [MISC] En cas d'arnaque on fait quoi ?

[Julien Escario]

Le 22/04/2020 à 09:55, Kevin CHAILLY | Service Technique a écrit :
> Question numéro 1 : vendent-ils aussi des fournitures de bureautique faisant 
> des photocopies ? 

Haha, alors c'est le même business model mais non ;-)

Là, on est vraiment dans l'arnaque (quoique les vendeurs de copieurs
...). Le client est certain de signer avec Orange du début à la fin.
On est à la campagne, c'est encore la société nationale des télécoms ici
et les arnaqueurs le savent bien.

Il y a une nette différence entre usurper clairement l'identité d'une
boite d'ampleur nationale et monter des contrats qui enchaînent le client.
Le deuxième cas se règle entre avocats devant un TC. Le premier, c'est
aux forces de police de le gérer.

Mais la boite en question est bien parisienne, pas d'inquiétude.

Julien


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

Re: [FRnOG] [MISC] En cas d'arnaque on fait quoi ?

[Julien Escario]

Le 21/04/2020 à 16:49, Oliver varenne a écrit :
> Bonjour à tous,
> 
> Question « droit » : on a rencontré quelques société déjà, malheureusement 
> pour nous, qui nous achètent des IPBX et des téléphones (nous sommes « 
> grossistes a valeur ajoutée » comme on dit), et les revendent en se faisant 
> passer pour Orange
> Généralement ça se passe comme ça :
> 
> Un centre d'appel à l'international appelle des prospects et tiens grosso 
> modo ce discours :
> «  bonjour, bidule de la société Orange, je vous appelle pour faire le point 
> sur votre installation »
> Au choix :
> « vous êtes pas client orange ? faisons le point je vais vous proposer 
> quelque chose de mieux »
> « vous êtes déjà client orange ? justement nous faisons le point avec nos 
> clients pour voir s'ils peuvent faire des économies »
[...]

On a eu un cas similaire ici avec une boite de télécom qui a ratissé les
petites communes et se présentant comme Orange et pour préparer la fin
du RTC.
Même chose : engagement 72 mois, tarif totalement délirant (100 €/mois
pour une ADSL + un tél) sur la base de 'vous n'avez pas le choix, sinon
on va couper votre service'.

Et on nous a appelés en tant que sous-traitants pour accueillir le tech
Orange qui venait poser l'ADSL.

On s'est fait un plaisir d'y aller, de discuter avec le maire et de leur
faire casser la commande avant la fin du délai de rétraction.
Mais ça a déclenché des quelques drames avec des conseils municipaux qui
sont tombés sur le maire qui validé le truc dans son coin.

A qui est-ce qu'on peut signaler ce genre de pratiques ? DGCCRF ? Pas
l'ARCEP, c'est certain, parce que ces arnaqueurs ne se donnent pas la
peine de se déclarer opérateur.

Julien


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

Re: [FRnOG] [TECH] QSFP+ vs SFP28

[Julien Escario]

Le 14/04/2020 à 15:35, benoit mordac a écrit :
> Bonjour,
> 
> Attention au SFP28, on se retrouve sur certains modèles de switchs à devoir
> choisir la vitesse du port (10Gb/s ou 25Gb/s) par groupes de 4 ports :
[...]

Merci à tous pour vos retours précieux. Donc à priori, le SFP28 avec
quelques ports QSFP28 semble plus future-proof.

Est-ce que quelqu'un a déjà testé ce genre de babasses :
https://www.supermicro.com/en/products/accessories/networking/SSE-F3548S.php

Ca semble se trouver entre 3000 et 4000 €, ce qui me paraît très correct
étant donné le fond de panier qu'il faut coller là dessus (1800 Gbps).

Et bonus, il semblerait que l'on puisse même faire du 1G (mais pourquoi
diable ?).

A première vue, je dirais que c'est un OEM brandé Supermicro, ce qui ne
me pousse pas vraiment à l'achat impulsif.

Julien


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

[FRnOG] [TECH] QSFP+ vs SFP28

[Julien Escario]

Bonjour la liste,
Une petite question rapide : je dois passer à la vitesse supérieure sur
notre stockage distribué, le NVMe commençant à avoir raison du 10G.

Du coup, est-ce que vous avez des recommandations entre le SFP28 et le
QSFP+ ? (outre le débit).

J'ai lu, par exemple, que le QSFP+ est en train de disparaître doucement
mais c'est dommage parce qu'il permet d'upgrader en douceur en utilisant
des break-out QSFP+ -> 4 SFP+ en attendant d'avoir plus de ports QSFP+.

Est-ce que, par hasard, on pourrait éclater un SFP28 en 2xSFP+ ? (j'en
doute très fortement vu que le SFP28 n'est pas un agrégat de canaux mais
une simple augmentation du débit).
J'ai lu qu'on peut utiliser des DAC SFP+ dans des ports SFP28 (et vice
versa semble t'il). C'est systématique ?

Et par curiosité, y aurait-il une différence notable de latence ?
J'image que la décomposition en 4 canaux puis recomposition du QSFP+
doit rajouter quelques (dizaines de) ns dans la communication ?

Note : dans mon use-case, c'est exclusivement du DAC puisque cluster de
stockage Ceph.

Je prends volontiers les conseils, et pardon si on est plus dans
l'application du réseau au stockage que dans du routage pur et dur.

Merci,
Julien


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

Re: [FRnOG] [BIZ] Devis Observium

[Julien Escario]

Le 08/04/2020 à 18:22, Michel Py a écrit :
>>> oups...@oupsman.fr a écrit :
>>> Perso, si je suis appelé à 3h du matin, j'aime bien avoir un support 
>>> joignable dans l'heure pour me dépanner.
> 
> A 3 heures du matin, le support c'est moi. Je n'ai pas le temps de perdre 3 
> jours à passer avec le niveau 1,2 et 3 du support pousse-bouton d'un vendeur 
> qui le sous-traite à Bangalore à des clampains qui sont ingénieurs réseau 
> comme moi je suis chirurgien dentiste.

Holà malheureux ! Et sur qui tu te dédouanes quand ça marche toujours
pas à 8h ?

Tu veux dire que ... tu assumes toi même le bon fonctionnement de tes
services ? Quelle audace !

Julien


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

Re: [FRnOG] [TECH] Hébergement local et internet mobile

[Julien Escario]

Le 04/04/2020 à 16:41, Eugène Ngontang a écrit :
> Hello la liste...
[...]
> - Quel est l'impact du DNS dans la consommation des données mobiles ?
[...]

Ah, ça, je peux répondre : l'optimisation de n'importe quelle image dans
une appli web fera gagner 50x ce que consomme le traffic DNS en terme de
volumétrie dans les tuyaux.

En gros, le problème n'est pas dans le réseau, il est dans le dev (ou le
graphisme en l'occurence) : une appli qui se contente de renvoyer
uniquement les infos nécessaires dans un format optimisé, ca change tout
en terme d'occupation des réseaux (et souvent des ressources système
côté serveur et terminal).

Julien


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

Re: [FRnOG] [ALERT] [natha...@ripe.net: [ncc-announce] [service] Accidental Deletion of ROAs]

[Julien Escario]

Bonjour,
Chez nous, les ROAs n'ont pas bougé. C'est en tout cas ce que dit le
dahsboard RPKI.

Un moyen tiers de vérifier ça autrement ? (mais j'imagine que BGPmon et
Qrator auraient levé des alertes, non ?)

Cela soulève une question interressante : quelles sont les bonnes
pratiques en matière de durée du cache de vos validators ?

Bonne journée,
Julien

Le 02/04/2020 à 11:20, Clément Cavadore a écrit :
> Hello les confinés,
> 
> Je confirme!
> 
> Sur plusieurs des LIRs et end-users que j'ai en gestion, j'ai du les recréer.
> Allez bien checker vos propres ROAs !
> 
> Clement 
> 
> Le 2 avril 2020 10:57:41 GMT+02:00, Stephane Bortzmeyer  a 
> écrit :
>> Ceci n'est pas un poisson.
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 


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

Re: [FRnOG] [MISC] Corona virus :, intervention pendant confinement

[Julien Escario]

Le 16/03/2020 à 18:59, Richard Klein a écrit :
> Le port du masque, des gants, de la ceinture,des bretelles et de l airbag
> pour moi ne servira à rien.
> Lorsque l'ami Corona va voler dans l'air il passera probablement dans la
> clim qui souffle du froid.
> Le virus va probablement s'endormir avec le froid et se mélanger avec la
> poussière des filtres pour muter avec les copains.
> Quand la clim va s'arrêter ou souffler du chaud le virus va se multiplier
> et se faire éjecter de son filtre pour saturer la pièce et atteindre son
> hôte.

Vérifie tes idées reçues sur ce virus : la clim ne l'interresse pas
beaucoup. Il se transmet assez mal de manière 'indirecte' avec une durée
de vie assez courte une fois sorti de son hôte.

En fait, dans son cas, c'est même plutôt un facteur de diminution de
l'infectiosité puisque tout ce qui est en sur-pression plaque les
goutellettes sur le sol et les murs. Moins de chance que ca reste en
suspension.

Mais les connaissances sur ce virus n'ont pas fini d'évoluer.

Julien


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

Re: [FRnOG] [MISC] le pétaoctet du pauvre

[Julien Escario]

Le 12/03/2020 à 18:40, Michel Py a écrit :
>>> Phil Regnauld a écrit :
>>> Faut jamais exposer CephFS directement aux utilisateurs finaux de toute 
>>> façon.
> 
>> Fabien Sirjean a écrit :
>> Je suis curieux, quel est le problème ?
>> Ici on hésite justement entre un gros RBD exporté par samba ou du CephFS...
> 
> Curieux aussi. Le gateway Samba directement connecté sur CephFS çà me parait 
> moins compliqué.
> 
> Je pense que je ne vais pas passer à Ceph, ceci étant dit. Trop compliqué 
> pour me petits besoins.
> 
> Michel.

Bah honnêtement, si tu as au moins trois noeuds à y consacrer, c'est
vraiment pas long et ça fait gagner un temps d'admin assez hallucinant.

J'avais aussi tenu ce discours il y a 5/6 ans, quand Ceph demarrait.
J'ai revu mon jugement en 2019, on a migré fin d'année et depuis, c'est
que du bonheur avec du Promox en hyperconvergé. On commence même à jouer
avec le support trim/discard et c'est *presque* out of the box (modulo
un kernel 5 pour le moment).

Julien


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

Re: [FRnOG] [TECH] Modem VDSL petit/qui marche ??

[Julien Escario]

Le 04/03/2020 à 11:49, x.r...@sipleo.com a écrit :
> Hello,
> 
> On a vu, on a testé et on est passé 
> Déjà on pose une condition lors de l'achat pour test on vous répond oui oui 
> ...
> A la mise en œuvre quand on doit faire et que l'on n'y arrive pas toujours : 
> oui oui 
> Après on se renseigne plusieurs mois après toujours rien et suivi du dossier 
> ...
[...]
> Les personnes sont sympas mais sur la maitrise du produit qu'ils marquent 
> Nascom, ce n'est vraiment pas ça.
> Si souci en production :( :(
> 
> Et donc en usage autonome on a le problème de NAT 1:1 VPN et en usage du coup 
> Modem uniquement VDSL/ADLS pas possible ...
> Pour nous c'est donc hors-jeux 
> 
> Xavier

Ca me rassure, tu as eu exactement la même expérience que nous.

On a demandé la doc du bouzin, jamais eue. En fait, je crois qu'elle
n'existe pas, tout simplement. Ou alors en chinois et ils n'ont pas eu
le temps de la traduire.

Julien


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

Re: [FRnOG] [TECH] Modem VDSL petit/qui marche ??

[Julien Escario]

Le 28/02/2020 à 08:16, Frank ALEXIS a écrit :
> Bonjour ensoleillé (si si ... ici c'est ensoleillé;-) !)

Pareil, bonjour !

> Je cherche un remplaçant à mes vénérables Netgear DM200 qui font le job pour 
> 50 balles, mais j'ai pas bien trouvé le truc qui me plait.
> 
> VDSL/VDSL2 (ADSL2 sous entendu)
> Mode bridge (un minimum)
> Ethernet
> Pas gros
> Pas cher (50/60 max)
> Stable
> Pas une bouse en performance
> Qu'on oublie posé au fond de la baie (forcément c'est pas rackable :-p !)
> 
> J'ai vu le TP-LINK TD-W9970 mais je sais pas trop.
> 
> Galère à trouver comme truc basique :-(
> 
> Merci à vous amis dans la matrice !
> Frank

Même problématique ici. J'ajouterais juste comme contrainte le support
du bi-vlan (835/850).

Si on était chez les Bisounours, je demanderais même que le bouzin
puisse être alimenté en PoE.

Julien


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