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

[Pierre Colombier via frnog]

Ah non David, je suis pas d'accord.

On sait bien que l'usage moyen est à moins de 50M. (même moins de 10M 
pour la plupart des gens) Mais l'usage moyen n'est pas le chiffre le 
plus pertinent.


Le client, pro ou GP, il a besoin de >1G burst pendant moins de 0.5% du 
temps et c'est cette pointe là qui lui donne l'impression de confort.


Après, c'est pas n'importe-qui qui a un PC avec de l’ethernet à plus de 
1G. Mais pour un gamer, la moindre update fait plus de 10Go, si il peut 
les avoir en moins d'une minute plutôt qu'en une heure, ça change 
radicalement son ressenti.


Pierre



Le 28/03/2024 à 10:37, David Ponzone a écrit :

Oui alors, vu le lectorat d’un tel site, ça me dérange beaucoup moins que quand 
c’est les OCEN qui basent leur marketing GP sur: « Bientôt 8Gbps, bientôt plus 
de streaming!», « Trop de lag dans Fortnite ? Choisissez le XGS-PON! 10G!».

Quand on voit la tronche de la courbe de conso moyen d’un abonné FTTH GP (ou 
pro d’ailleur), on ne sait même pas comment expliquer ça à un client (pro) 
tellement on a l’impression de plus être crédible quand on lui dit que son 
besoin réel, c’est même pas 50Mbps.

David


Le 28 mars 2024 à 10:28, Samuel Thibault  a écrit 
:

David Ponzone, le jeu. 28 mars 2024 10:10:59 +0100, a ecrit:

Euh non, je pense que la comparaison avec le FTTH est pour être compréhensible
par des novices.

Bien sûr, mais le message devient juste complètement *mensonger*. Il
dit qu'Internet va être un million de fois plus rapide, c'est juste
complètement faux.

Et le fond derrière, c'est laisser croire que du coup on serait
magiquement un million de fois plus heureux.

Samuel


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



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

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

[Pierre Colombier via frnog]

Vu toute l'armature nécessaire et la technique de pose, j'ai dans l'idée 
que le prix d'un câble sous-marin n'est que très très peu lié au nombre 
de fibres qu'il y a dedans. Mais en fait, j'y connais rien. Un expert 
peut-il confirmer ou infirmer cette intuition ?



Le 28/03/2024 à 09:57, Rod Beck a écrit :

The question, gentlemen, is over what distance can this technology work? The 
consensus for submarine cable systems is that transmission rates are quickly 
converging to the Shannon Limit. And the focus has been increasing the number 
of fibre pairs, not transmission rates per pair. Alcatel's spatial division 
multiplexing 'philosophy' was the key breakthrough. It uses relatively low 
transmission rates per fibre pair in order to conserve power and enable cables 
with higher fibre pair counts.

Remember these academics have their own agenda as well. Fame and money. So I 
would temper your enthusiasm.

Best,

Roderick.




[https://lh6.googleusercontent.com/2Lt_FJczBnPSUVs0JtgFSEE6fuziTBUYnu5DNq7DbaHJYMBySeKDNp6ky9fv2ZWitaRolkQMR0HSYAjjdUM-gPjMmFr6UnBhtrqwCia4-yVzmmqhyQtc-ad4xrS_rOVnPbkMDOFfh8OhRQhNA_O0QSw]

Roderick Beck

Global Network Capacity Procurement

Budapest:36-70-605-5144

New Jersey: 908-452-8183

Email: rod.b...@unitedcablecompany.com

www.unitedcablecompany.com



[https://lh6.googleusercontent.com/9R8wAqKpQlsGGeLxkitsOAGZIQucIAtkshtukANvmidSqz6q6w8bfgw1ayLaQLu77e2px7kf_Z-COzwKMwzoOaamiT8nQTWBY4SE5bJbgHvfBDpHFO2hot6tXqnoWYa3yY2p2l73e70mLuf930n9PKQ]
[https://lh6.googleusercontent.com/hfZwsEtrU6zRgcl2B--cHNIQoviPy66lZXM-SPu-enHxzN4PTw-dn1561xJUY_PwXLBZrbwrbT5e8un3NttT_E4IMFTa65qHiW0AufGmGjEWhkMGr-zQWJ5y20Mp7aBfGzIJtB7U8u12DWutCGFr6go]
[https://lh4.googleusercontent.com/QlM9Q72tZY7lyyTh46fFRX4812LGdtEnBEFfpd4m3ybv2msBvSJCsAwwjCBCeTVniXqGwoqGsmuerW9bZZ_VYsRzJ8gVPxQEWVPa82Rs5ELajVXrNnbFlGgi6SzxOjRHT8QPmtb3UhVs_YRmxQjY3Uo]

[https://lh6.googleusercontent.com/utA6pbJLZJpgC_rlNXfhviBHRjT4pyeShbRvycb8HG3_DFzbMXuo136B2hLqlphCvLhy2ZmnsrHMVAk-1hWpTRr3eDqQzfXT5VYftw_P8fzUbpgbmsVFnZf2WQVTsL97wpeVqRZbMOf7N95Eq4Up-as]


From: frnog-requ...@frnog.org  on behalf of Samuel Thibault 

Sent: Thursday, March 28, 2024 9:32 AM
To: frnog-tech 
Subject: Re: [FRnOG] [TECH] 300Tbps par paire

David Ponzone, le jeu. 28 mars 2024 08:13:59 +0100, a ecrit:

Titre douteux mais la perf est là :

https://interestingengineering.com/innovation/4-5-million-times-faster-internet-aston-university-makes-it-possible

Le titre est plus que douteux puisqu'il se compare sur la capacité
actuelle délivrée plutôt que la capacité théorique de
l'infrastructure fibre posée avant leur innovation.

La question que je me pose, surtout, c'est: mais que va-t-on bien
pouvoir faire de 300Tbps à la maison (puisque c'est la cible). Est-ce
que le 1Gbps actuel (ou éventuellement 10Gbps) ne suffit pas pour
n'importe quel usage qu'on pourrait vouloir raisonnablement à la
maison ? Oui, je sais bien, 640Ko, toussa, mais à un moment, la télé
1000k, on n'est juste pas capables de la percevoir...

Il faut qu'on arrête cette course, c'est juste complètement débile.

Samuel


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

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



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

Re: [FRnOG] [TECH] Single Pair Ethernet

[Pierre Colombier via frnog]

10M, 1km, poe ? pour l'IOT, c'est génial.

Je sais pas si c'est au point mais en tout cas ça m'intéresse !


Le 08/03/2024 à 19:36, Fabien Sirjean a écrit :

Bonjour la liste,

J'ai récemment entendu parler pour la première fois de Single Pair 
Ethernet (10BASE-T1S / 10BASE-T1L), dont les specs ont l'air 
prometteuses (notamment en environnement industriel) :


 - 10 Mbps sur une seule paire de cuivre, avec des standards en cours 
de travail pour monter à 10G voire plus ?

 - Distance jusqu'à 1 km
 - PoE (ou plutôt PoDL) jusqu'à 50W

Alors, poudre verte ou bien véritable intérêt ? Des retours 
d'expérience en la matière ?


Bon week-end,

Fabien


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



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

[FRnOG] [TECH] IEEE 1588 Precision Time Protocol

[Pierre Colombier via frnog]

Bonjour,

je suis à la recherche d'informations et de retours d'expériences 
concernant la norme IEEE1588.


J'en ai découvert l'existence en repérant que le PHY Ethernet de mon SoC 
disposait de lignes d'IO "sync_in"/"sync_out" qui semblent être en 
relation avec ce protocole. mais sans beaucoup plus de précision sur 
l'usage qui devrait ou pourrait en être fait.


L'accès à la norme elle-même est restreint par un paywall, et j'ai du 
mal à me faire une vue d'ensemble.


Déjà je souhaiterais comprendre si c'est simplement un "gadget" 
technologique ou si, au contraire, c'est largement adopté et utilisé 
dans l'industrie.


Ensuite, pour la culture, j'aimerai comprendre à quel niveau on se 
situe. Il y a des elements qui sont directement au niveau du PHY ce qui 
suggère des couches très basse. Mais il y a un pendant logiciel plus 
haut niveau...  C'est confus.


Bref, si quelqu'un peux m'expliquer ça en quelques phrases ou me donner 
un lien vers une explication pas trop absconse, je suis preneur.


Merci d'avance.








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

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

[Pierre Colombier via frnog]

Je ne sais pas ce que vous en pensez mais ipv6 only, moi je veux bien ! 
C'est quand on veux !


Par contre, la dual-stack, c'est juste 2x plus de boulot à maintenir (et 
au moins 3x plus à monitorer) pour rien.


A partir du moment où on est obligé de maintenir le v4, avoir du v6 en 
plus ne présente quasiment aucun intérêt.


En fait, ce sont précisément les appareils ou l'adressage direct d'ipv6 
serait intéressant qui le supportent peu ou mal, à commencer par la VOIP.


Si la VOIP pouvait être en v6, mais qu'est-ce que ça serait plus simple !!!

Parce-que les empilages de traversées de NAT ou de firewall, c'est sans 
doute largement mieux qu'il y a 10 ans mais ça reste quand même bien 
bien foireux selon les combinaisons de matériel ou d'opérateur.



Je pense que la solution serait que les opérateurs de backbone/tier1 se 
mettent d'accord pour définir et annoncer une date d'extinction du 
routage ipv4 global.


Sinon, si on attends que ça tombe en désuétude tout seul, on y est 
encore dans 50 ans.


ipv6 existait déjà quand je suis rentré sur le marché du travail. Il y a 
des chances que je ne voie jamais l'extinction d'ipv4.



qu'en pense la liste ?




Le 12/02/2024 à 08:16, Bertrand FRUCHET via frnog a écrit :

Bonjour la liste,

A ce jour nos principales difficultés pour basculer en dual stack IPv6 
et surtout en IPv6 Only se résument à peu de choses.


Les grands faiseurs (nationaux ou internationaux) n'y sont pas pour 
grand chose, et les technos de passerelle (6to4, dns64 et affiliées) 
ne suffisent pas :


- La VoIP : les devices (fabricants) et les trunks (opérateurs)

- les copieurs, imprimantes, scanners et autres prestataires qui les 
pilotent


- les logiciels métiers où les liaisons entre applications sont 
définies dans des champs texte ne supportant que l'IPv4, voire même ne 
supportant pas les noms DNS.


- les devices : switchs, points d'accès, caméras vidéos, portiers, 
domotique d'entreprise, etc.


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


Bonne semaine à tous,

Cordialement,

Bertrand.


Le 12/02/2024 à 00:24, Radu-Adrian Feurdean a écrit :

On Sun, Feb 11, 2024, at 19:31, Yann S. O.A. wrote:
La France bonne élève pour le coup. Il nous manque principalement 
SFR en

grand public fixe et Free en mobile il me semble ?
SFR : it's complicated. Il y a du SFR qui fait du v6 depuis des 
années et du SFR qui 
Free Mobile : c'est du opt-in pas très évident. Je suppose le minimum 
syndical pour l'histoire "5G, IPv6, ARCEP, contrat".



Après il y les entreprises...

... et surtout les fournisseurs de contenu locaux (PAS les GAFAM) ...
A quelques exceptions près (oups, un truc d'SFR fait/faisait partie), 
pour eux l'IPv6 c'est du NIH (Not Invented Here). Peut-etre encore 
quelques-uns qui arrivent via Cloudflare ou autre CDN "v6 friendly".



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




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



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

Re: [FRnOG] [ALERT] Covage en vrac dans le Grand Est

[Pierre Colombier via frnog]

je ne sais pas si il y a un rapport mais il y a eu un gros coup de 
pelleteuse sur un POP covage dans le centre de Clermont Ferrand à 8H40 
ce matin.



Le 16/11/2023 à 10:03, Pierre Moreau via frnog a écrit :

Sur les nôtres en Saône et Loire, 0% de pertes ce matin.

Pierre


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Julien 
Issler
Envoyé : jeudi 16 novembre 2023 09:49
À : frnog@frnog.org
Objet : Re: [FRnOG] [ALERT] Covage en vrac dans le Grand Est

Bonjour,

perso j'ai encore un peu de packet-loss (1 - 3%) sur pas mal de mes liaisons 
Covage ce matin, chez vous tout est nickel ?

Ou vous pensez qu'ils sont en train de ré-équilibrer le routage dans le sens 
inverse des tentatives de hier ?

Sur le fond, oui, un compte rendu serait vraiment bien, avec des photos 
avant/pendant les travaux de soudure etc... Si on peut montrer au client le 
câble avec  fibres arrachées à ressouder, ça permet déjà d'expliquer le 
temps. Sur l'origine, pelleteuse, vandalisme, etc... aussi.

Julien


Le 15/11/2023 à 19:36, David Ponzone a écrit :

18h00 : Notre équipe a repris l’ensemble des soudures. Le trafic est revenu à 
la normal a 17h34. L’incident générique est terminé. Nous vous invitons à 
revenir vers nous si vous constatez des dysfonctionnements après 17h34.

Bon, autant vous dire qu’on va pas les lâcher pour comprendre pourquoi leur 
réseau n’est pas redondant au moins sur son axe principal.


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

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



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

Re: [FRnOG] [TECH] Découverte de plusieurs failles par fuzzing BGP

[Pierre Colombier via frnog]

Pour information, Il y a un problème similaire mais différent touchant 
l'encodage de la taille d'attribut sur les ubiquity EdgeOS


Selon le RFC9072

In the event that the length of the Optional Parameters in the BGP
OPEN message does not exceed 255, the encodings of the base BGP
specification [RFC4271] SHOULD be used without alteration.
Configuration MAY override this to force the extended format to be
used in all cases; this might be used, for example, to test that a
peer supports this specification.  (In any case, an implementation
MUST accept an OPEN message that uses the encoding of this
specification even if the length of the Optional Parameters is 255 or
less.)


 Le problème est que rien n'est explicitement dit pour les messages 
UPDATES.


le 16 janvier 2023, les routeurs ubiquity ne semblaient pas respecter ce 
MUST (pour les UPDATE).


Par exemple un UPDATE avec attribut AGGREGATOR avec le flag 
Extended-Length faisait reseter la session)



Le bug a été (longuement) reporté mais je ne sais pas si ça a été patché 
depuis car après deux bons mois d'attente, on a changé de routeur.




Le 29/08/2023 à 18:04, Hervé BRY via frnog a écrit :

Bonsoir,

Petite lecture du jour qui mérite attention sur le blog de l'ami benjojo
(bgp.tools) :
https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling

Il semble que les routeurs Juniper, Nokia et Extreme Networks, ainsi
que FRR et OpenBGPd soient affectés par des bugs qui peuvent entraîner un
shutdown de session BGP lorsqu'une route avec un attribut corrompu est
reçue. Selon les cas une simple option peut contourner le problème, dans
d'autres aucun patch n'est encore disponible.

Hervé BRY
Head of Infrastructure
Geneanet (http://www.geneanet.org)

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

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

Re: [FRnOG] [MISC] Passages de câble, voisinage et propriétés privés.

[Pierre Colombier via frnog]

disclaimer : Ce que je vais dire n'est que mon avis et n'a pas de 
fondements juridiques.


il me semble que rien n'oblige le voisin a être coopératif, ou en tout 
cas pas sans procédure bien chiante. Reprendre l'ancien tracé me semble 
donc exclus.


C'est de toute façon une bonne chose que de choisir une méthode 
d'installation qui ne nécessite pas son concours. Ni aujourd'hui, ni 
plus tard.


Maintenant, pour le client qui demande la fibre, il est normal qu'il 
veuille que les travaux restent assez discrets mais si il ne veut pas 
non plus qu'on touche à son mur, c'est qu'il ne la veut pas vraiment.


Faut pas s'acharner : Revenez quand vous aurez vraiment envie. Au revoir.



Le 29/08/2023 à 12:34, David Ponzone a écrit :

Franchement, sauf si tu factures cher, je te recommande de sortir de ce genre 
d’embrouilles entre un particulier et le déploiement fibre Grand Public, parce 
que quand ça foire, ça foire bien foire, et quand il y a en plus un particulier 
qui fait chier, y a pas grand chose à faire.
Que du temps à perdre et rien à gagner (puisque ça ira jamais assez vite pour 
un client particulier « VIP »).

Après, Orange peut pas l’empêcher de rester en ADSL si la fibre est pas dispo à 
son adresse (information publique).


Le 29 août 2023 à 12:28, Carroussel Informatique  a 
écrit :

Bonjour à tous et toutes.

Je ne suis pas certain de la catégorie utilisé, à priori c'est plus du 
juridique que du technique...

J'ai un client particulier, qui veux passer de SFR à Orange. Orange lui a 
envoyé une box fibre, incompatible avec sa ligne actuelle, encore en cuivre.
Il faut donc virer le câble de cuivre et tirer une fibre à la place.
Problème : c'est un vieil immeuble, en fait je pense qu'il s'agissait d'une 
très grosse maison de village, qui a été coupé en deux, bref...
Et le fil de cuivre passe chez le voisin, avant d’atterrir "quelque part" chez 
mon client, en faisant au passage des boucles exotique dans les murs.
Problème 2 : Le voisin est un spécimen asser courant de grossus connardus 
vulgaris, qui ne fait rien pour aider. Cela fait trois fois que les techos se 
déplacent pour tirer la fibre et que le gros con n'est pas là, ou leur refuse 
l’accès au local.
SFR s'en fout, Orange... ne peu légalement pas forcer la porte du voisin, ni le 
ligoter à une chaise pendant que ses techniciens tire le câble.
D'un point de vue technique, ça résoudrait bien des problèmes, mais en terme 
d'image, il parait que ce n'est pas terrible.
Bref, Orange a envoyé un tas de papiers, mon client qui est âgé et peu patient, 
a tout envoyé bouler, et a fait un scandale à la mairie, la dessus, les 
assurances s'en sont mêlés, et mon clien t les a envoyé bouler aussi.
Bref, ça n'avance pas.
J'ai essayé de lui expliquer qu'il fallait faire un trou dans SA façade pour 
faire passer la fibre, mais je sort de ma zone de compétence (je répare les 
ordis sous windows moi madame !)

Question : A qui appartient le fil de cuivre ? à Orange ? Au voisin ?
Et si l'on décide de laisser tomber le remplacement du fil de Cuivre pour 
bypasser le voisin chiant, qui doit faire les travaux pour faire passer la 
fibre de la rue à la maison de mon client ?
Je vis en Cambrousse, dans un vieux village, et des cas tordus, j'en ai 
quelques un, et je ne suis pas forcément le plus compétent pour répondre à ces 
question.
Et l'aide grand public des FAI, ben c'est pas toujours ça non plus.

Si vous pouvez m'éclairer, ou m'orienter dans la bonne direction, merci 
d'avance.


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


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



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

Re: [FRnOG] [MISC] Foudre

[Pierre Colombier via frnog]

on est pas vendredi mais ça dépends...

En courant tu n'a qu'un seul pied qui touche le sol à la fois...

;)



Le 28/08/2023 à 09:48, Toussaint OTTAVI a écrit :


Le 28/08/2023 à 09:06, Stéphane Rivière a écrit :

Quand ça grésille en tête de mat ou si ça sent l'ozone, tu te casses.


Hahaha, çà sent le vécu :-)

Tu te casses, mais pas en courant ! Le calcul de la différence de 
potentiel entre tes deux jambes en raison de la résistance électrique 
du sol, c'est l'exercice de base après une formation foudre :-D



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



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

Re: [FRnOG] [MISC] Foudre

[Pierre Colombier via frnog]

Tant qu'on y est j'ai d'autres interrogation concernant ce que 
représente la foudre en matière de courant.


Quand la décharge de foudre lieu, l'énergie se dissipe essentiellement 
dans l'arc et tout ce qui a le malheur d'avoir une résistance élevée 
mais c'est quoi le courant qui passe dans la pointe et la connexion de 
terre ?


Des dizaines ? des centaines ? des milliers d'ampères ? Parce que les 
câbles de paratonnerre ont des sections impressionnantes mais on ne sais 
pas bien si c'est dimensionné pour ne pas fondre ou bien si c'est pour 
qu'il y ait vraiment un un gradiant de tension négligeable entre le haut 
et la bas quand ça claque.


Les professionnels ont l'air d'appliquer des recettes mais sans vraiment 
savoir les ordres de grandeur du phénomène.


La question derrière la question est de savoir en fonction de la qualité 
de la connexion et de la prise de terre quel est le niveau de protection 
qu'on obtient.


genre est-ce qu'on évite juste l'incendie du bâtiment mais que toute 
l’électronique flambe, ou bien est-ce que ça peut épargner 
l’électronique à l'intérieur, ou bien est-ce qu'on peut rêver que les 
antennes sur le mat juste en dessous de la pointe de choc ne soient même 
pas affectées ?



Autre question : en cas de décharge de foudre, Localement, la terre 
risque d'avoir un potentiel très différent de celui du fil neutre de 
l'alimentation électrique. Comment ce problème est-il géré ?




Le 27/08/2023 à 07:39, Raphaël Jacquot a écrit :



Le 27/08/2023 à 04:43, Jérôme Quintard a écrit :

Hello la liste,


Bonjour,

La foudre nous a détruit plusieurs switchs en passant par un 
interphone IP sur un premier bâtiment et un lecteur de badge connecté 
à une alarme IP sur un second bâtiment.


as tu un moyen de connaitre le point d'impact ? quelque chose me dit 
que la protection parafoudre du bâtiment est non conforme.


Dans les deux cas, seul le switch directement connecté à été détruit. 
Rien au niveau des autres membres du stack (sauf un dont le PoE a 
cessé 24h après), ni des autres périphériques connectés, ni des 
étages supérieurs (connectés de toute façon en fibre).


Les intervenants sur place nous ont parlé d’une fumée épaisse dans 
chaque salle. Vérification faite, seules les alimentations (et un 
ventilateur) ont été détruites (sur des Cisco 3750).


Dans les faits :

- On est étonné de cette fumée (fusion des bobines ?)


puisque ce sont les alims qui ont cramé, je pointerai plus les 
condensateurs chimiques, grand pourvoyeurs de fumée bleue ;)


- Aucune coupure de l’onduleur (les baies étaient fonctionnels), idem 
coté différentiel…


- J’aurai bien changé 100% des équipements connectés pour ne pas 
prendre de risque. Comme réagiriez-vous ? Sur l’extérieur les câbles 
ont carrément fusionnés entre eux.


En bref avez vous un REX sur genre de pannes.


remplacer tout ce qui sent bizarre, faire contrôler l'installation 
électrique, en particulier le coté protection foudre



Jérôme


Raphaël
qui est confronté régulièrement à la foudre dans les montagnes, mais 
qui a rarement perdu du matériel...



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



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

Re: [FRnOG] [MISC] Je recherche un clavier...

[Pierre Colombier via frnog]

J'utilise ça : 
https://www.razer.com/fr-fr/gaming-keyboards/razer-blackwidow-v3


C'est un peu cher mais c'est de la bonne came et j'en suis très satisfait.

le toucher est assez proche du fameux ibm. (du moins du souvenir que 
j'en ai et qui commence à dater.)


Le chassis est en métal assez lourd et stable (mais moins que le ibm) et 
le repose poignet est dur (j'aime pas les trucs à coussins)


Attention la marque a d'autre produits nettement moins quali.


Note au sujet du RVB adressable avec des motifs halacon, c'est rigolo 5 
minutes mais c'est plus dérangeant qu'autre chose et on revient 
rapidement à une conf statique.


Par contre le rétroéclairage, je trouve ça vraiment chouette quand on 
travaille dans une grotte.


Pour gérer ça sous Linux : installer openrazer + polychromatic



Le 12/06/2023 à 11:54, Gwenaël Oberlinger a écrit :

Hello,

Mes collègues sont à fond sur celui là depuis quelques semaines:
https://www.keychron.com/products/keychron-k10-pro-qmk-via-wireless-mechanical-keyboard



Perso pas fan des claviers mécaniques (j'ai essayé quelques uns).




On Mon, 12 Jun 2023 at 13:50, Stéphane Rivière  wrote:


Olivier,


J’en trouve quelques-uns sur internet, mais à des prix indécents… J’aime

bien ce clavier, mais je ne suis pas prêt à le payer un rein non plus.
Naaannn... C'est du n'importe quoi !

Si quelqu’un à un clavier model M qu’il souhaite vendre pas trop cher,

qu’il me contacte.
J'ai donné tous mes claviers M il y a une dizaine d'années à des
colistiers du bar@ovh... Quand je vois les prix aujourd'hui... Nawak :()

Si ça peut te consoler, on a oublié comme ils étaient quand même
horriblement bruyants, _très encombrants_ et nécessitaient un adaptateur
ps2/usb...

On utilise à la boite des claviers dell _pro_ multimedias, pratiques
pour les touches reprogrammables et le contrôle du volume. Silencieux,
pas encombrants, bonne frappe.

Sinon t'as des boites qui refont des copies (pas de lien désolé).


(Ps : si jamais la meme personne à un IMB PS2 model 80 … c’était mon

premier ordinateur. Nostalgie)

De mon coté, c'était un Telex (la marque US) à cartes enfichables (cpu
comprise) ou, chez les clients (beaucoup beaucoup beaucoup moins bien)
un BM 30 (BM = Bull Micral ;)

J'avoue aucun regret devant ma station 43" 4K écran mat et Nuc Intel
Nvme 1To, i7 trapu et 64 Go de ram sous Ubuntu 22.04 LTS bien désnappée.

L'IT, ça n'a jamais été mieux avant ;>

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


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






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

Re: [FRnOG] Re: [ALERT] Temps pluvieux sur le DNS

[Pierre Colombier via frnog]

Je pense qu'on parle du software. En tout cas c'est ce que suggère la 
partie entre parenthèses. Mais ça peut pas faire de mal d'interpréter au 
plus large.


Remarque : on pourrait peut-être réétiqueter ce fil en [TECH] ? non ?


Le 14/04/2023 à 20:17, Erwan David a écrit :


 Practice 4

Authoritative and recursive DNS service *MUST NOT* coexist on the same 
DNS server. In the context of authoritative servers, this means you 
*MUST* disable recursive DNS resolution on servers configured to serve 
authoritative DNS data (if the software allows running both 
authoritative and recursive at the same time).


Je me demande ce qu'ils entendent par "serveur" :  serveur physique ? 
VMs dans un même cluster ? conteneur/jails différentes sur le même OS 
? Différent services, sur des IP différentes arrivant sur la même 
instance d'OS+userland ?




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



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

Re: [FRnOG] [TECH] Appel aux retour d'expérience LAN ipv6 single stack.

[Pierre Colombier via frnog]

merci pour vos réponses.

Sur le plan technique c'est à peu près ce à quoi je m'attendais.

mais un pb qui m'interpelle avec le DNS64 c'est que c'est en quelque 
sorte un résolveur menteur.


Et certes, c'est pour la bonne cause, mais il n’empêche que même si 
c'est pas malicieux, ça peut quand même être mal perçu voir générer des 
alertes de sécurité.


est-ce qu'on modifie aussi les enregistrement spf avec des ip4: dedans ?

DNSSEC ?

Et puis un usager reste libre d'utiliser le résolveur de son choix. Ou 
alors d'avoir une application qui au lieu d'employer la résolution de 
nom configurée du réseau fait du DOH sur Cloudflare qui ne sera pas au 
courant qu'il faut générer des  dans le bon préfixe.


Du coup j'ai de sérieux doutes sur le fait que ça puisse se faire de 
façon vraiment transparente et c'est sur ce point que les lumières de la 
liste m'intéressent.




Le 27/01/2023 à 12:48, Willy Manga a écrit :

Bonjour,

On 27/01/2023 14:24, Pierre Colombier via frnog wrote:
Bonjour, j'aimerai savoir si certains d'entre vous on déjà essayé de 
passer un LAN en ipv6 seul avec un nat 6to4 sur la gateway (voir 
encore plusieurs sauts plus loin) pour aller consulter les sites qui 
sont uniquement accessibles en v4 ?


Si possible il faudrait raccourcir le nombre de sauts (au moins avec 
la passerelle NAT64); c'est au moins ce que peut permettre IPv6 dans 
certains contextes.


Et si oui, comment gérez vous la problématique du DNS64 ? (C'est à 
dire fournir les records  dans le préfixe 6to4 pour les sites qui 
n'ont que du A.)


Plusieurs résolveurs l'implémentent soit en se servant d'un préfixe 
generique prevue  ( 64:ff9b::/96 ) ou bien en choisissant un /96 dans 
son propre bloc. Mais bien sur ceci n'est qu'à usage interne.
Ici: unbound,bind mais powerdns-recursor et knot-resolver font aussi 
l'affaire.


Pour simplifier, l'hôte envoie une requête , le résolveur constate 
qu'elle n'existe pas et 'fabrique' une réponse en  en se servant 
du préfixe  configuré plus haut.
L'hôte se servira donc de cette adresse factice pour échanger à l'aide 
de la passerelle NAT64.





Et finalement avec quel niveau de succès et/ou d'emmerdement ?


Tant que la resource à distance s'identifie avec un nom complètement 
qualifié, ça juste marche.


Sinon il faut envisager une autre technique de transition du genre 
464XLAT







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

[FRnOG] [TECH] Appel aux retour d'expérience LAN ipv6 single stack.

[Pierre Colombier via frnog]

Bonjour, j'aimerai savoir si certains d'entre vous on déjà essayé de 
passer un LAN en ipv6 seul avec un nat 6to4 sur la gateway (voir encore 
plusieurs sauts plus loin) pour aller consulter les sites qui sont 
uniquement accessibles en v4 ?


Et si oui, comment gérez vous la problématique du DNS64 ? (C'est à dire 
fournir les records  dans le préfixe 6to4 pour les sites qui n'ont 
que du A.)


Et finalement avec quel niveau de succès et/ou d'emmerdement ?







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

Re: [FRnOG] [TECH] Retour d'expérience routeur Mikrotik gamme CCR

[Pierre Colombier via frnog]

Je suis d'accord. Les pb d'alim n'arrivent pas souvent ou en tout cas 
c'est pas le problème le plus préoccupant.


Sur les modèles équipés de 2 alim AC : J'ai une vingtaine d'unités : 0 
pb en 7 ans.



Oui, le jour où une alim claque, je changerai le chassis entier, (avant 
de changer l'aim en atelier) de toute façon je dois bien prévoir le coup 
au cas où ça serait tout le chassis qui claque ce qui pour l'instant ne 
m'est pas encore arrivé.


J'ai de toute façon très largement plus de downtime lié à des gitans qui 
font des branchements sauvages sur l'alim electrique d'un POP ou 
vandalisent le groupe electrogène pour piquer le gasoil.



BGP sur un 1036 en v7 ? ça marche ?

J'ai testé sur un CCR2004 en v7.0.x avec 2 full et même sans filtres, il 
en pouvait plus...


Je compte refaire des essais fin octobre sur des plus musclés en v7.5.



On 08/10/2022 11:08, Mickael MONSIEUR wrote:

On assemble nos serveurs supermicro, donc ouvrir un chassis mikrotik
pour changer l'alim 230v/12v ça nous fait pas peur ;)
Pour la redondance on a un CCR1036 qui était en v6 et qu'on a passé en
v7 depuis peu, et OSPF.
On ne fait pas de dialup donc je saurais pas te répondre.

Le sam. 8 oct. 2022 à 10:31, David Ponzone  a écrit :

Et tu prévois de gérer comment les alims non-hotswap quand ça va péter ?
Swap de chassis entier ?

Pour du border, c’est quand même couillon d’avoir un downtime pour changer une 
alim.

Pour BGP, +1.

Mais, pour MPLS, je sais pas si c’est mieux côté "dialup".
En V6, il est impossible de mettre un user radius dans un VRF. Il faut mettre 
des trucs en dur dans la conf pour chaque user. Welcome to 1990.
C’est corrigé en V7 ?
J’avoue que j’ai pas encore pris le temps de monter un CHR en v7 pour vérifier.


Le 8 oct. 2022 à 10:22, Mickael MONSIEUR  a écrit :

Bonjour,
Depuis Juillet on a un CCR2116 en prod avec 2 full tables v4 et v6, ça
va très bien. La gestion des filters, des communities est quand même
beaucoup mieux qu'en v6.
cordialement

Le ven. 7 oct. 2022 à 11:53, Etienne LEFAIVRE
 a écrit :

Bonjour la liste,

Je me permets de vous solliciter pour avoir votre retour d’expérience
sur la gamme CloudCoreRouter de Mikrotik.
J'ai un bon retour d'expérience sur cette marque pour du petit routeur à
déployer chez le client final.
Sur un modèle comme le RB3011 par exemple, ça tient bien le gigabit même
avec du firewalling + QOS VOIP pour un coût très raisonnable.

En revanche, je suis pour le moment assez sceptique pour racker du
Mikrotik en cœur de réseau...
Mon besoin est de remplacer un ASR-1002 qui est actuellement utilisé
comme routeur de bordure.
Ce routeur s'occupe du BGP pour gérer 2 fournisseurs de transit +
peering. 2 ports 10G utilisés.
Il n'a que 4Go de RAM (2Go dispo pour IOSD) et commence donc à montrer
ses limites pour BGP...
Je suis séduit sur le papier par le modèle Mikrotik CCR2116-12G-4S+ (<
1000€).
Financièrement, l'écart est tellement énorme entre du Cisco broker et du
Mikrotik tout neuf que le doute s'installe ! (surtout que nous doublons
l'investissement pour garder du spare au cas où)

Je prends donc avec plaisir vos retours sur cette gamme.
Merci d'avance et bon appétit !

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


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


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



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

Re: [FRnOG] [TECH] Retour d'expérience routeur Mikrotik gamme CCR

[Pierre Colombier via frnog]

Sinon, sur le fond, j'ai déjà fait un retour sur du CCR2004 lors de la 
sortie de ROS7 en stable


A l'époque c'était assez décevant. => fouillez l'archive frnog

ROS7 ayant muri, je compte faire de nouveaux essais prochainement.



On 07/10/2022 16:11, Pierre Colombier via frnog wrote:

euh sur ce coup là, je ne suis pas d'accord.

Tous les produits de la gamme "pro" ont une alim 220V intégrée, 
certains une double, d'autre non.



Sur les petit routeurs et switchs, milieu de gamme quasiment tout est 
compatible POE passif 24V ou utilise une alim DC 24V séparée. voir les 
deux pour la redondance mais la redondance n'est probablement pas 
l'objectif sur cette gamme de produits.


Les produits POE 802.xx "af" ou "at" (souvent des AP wifi) sont tous 
compatibles avec du 24V passif.


Il n'y a que les tout petites box qui sont parfois en micro-usb (5V) 
ce qui est finalement pas mal pour faire de boites à VPN qu'on 
alimente avec le port usb de son ordi.



Alors ok, c'est un peu diversifié mais "délire complet" ça me semble 
très très excessif.






On 07/10/2022 12:52, David Ponzone wrote:
Oui, encore un truc qui va pas chez MK: la non-cohérence des 
équipements niveau alim….


C’est du délire complet (un coup AC/AC, rarement hotplug, parfois 
POE-in/DC, parfois les 3, à croire que ça les éclate).


Donc pour Etienne, ça serait plutôt:

CCR2216-1G-12XS-2XQ (les ports 25G semblent supporter le 10G)
CCR1072-1G-8S+

C’est marrant, dès qu’il y a 16GB de RAM et des alims hotplug, le 
prix tape un peu plus :)
Ca reste raisonnable par rapport à l’équivalent Cisco ou Juniper en 
broke (difficile d’être à moins de 10k€).


Le 7 oct. 2022 à 12:20, Samuel Chesnel  a 
écrit :


Lo,

+1 pour le soft.
+ le Hardware, alimentation pas simple à remplacer en cas de 
défaillance !


Le ven. 7 oct. 2022 à 12:09, David Ponzone <mailto:david.ponz...@gmail.com>> a écrit :
Il y a eu un long échange à ce sujet sur la liste y a pas très 
longtemps il me semble, faut vérifier l’archive.

C’est de toute façon un sujet récurrent.

Niveau HW, le matos est fiable (je parle pour les anciens modèles, 
personne a de recul sur le CCR2116).

Après, le problème c’est le software.
Il y a 2 aspects:
-le CLI: personnellement, je ne me vois pas gérer des 
transits/peerings avec Router OS, j’ai bien trop d’habitudes en 
Cisco-like ou Juniper-like.
-le CPU: c’est plus compliqué. Jusqu’à la R6, BGP n’était pas 
multi-threadé, et ça devait changer en R7. Le problème que j’ai avec 
la R7, c’est que pour une MAJ qu’on a attendue littéralement 5 ans 
(plus ?), je trouve que sa sortie a été un total non-évènement et je 
ne sais pas quoi en penser. Au final, je ne m’y suis pas intéressé, 
donc je sais pas trop de quoi elle est vraiment capable. J’ai mis à 
jour un Mikrotik en R7 en tout, sur un bon paquet. Ca en dit long 
sur mon niveau de confiance :)


A mon avis, tu peux faire un truc.
Tu mets un RB3011 en R6 avec 2 sessions BGP vers ton ASR1002, en lui 
envoyant le max de préfixes qu’il peut tenir avec son petit 1Go de RAM.
Tu fais des clear, tu regardes combien de temps il met à recevoir 
les préfixes et converger (donc tu regardes à combien le CPU monte 
et quand il revient à la normale).

Ensuite tu le passes en R7, et tu compares.

Le 7 oct. 2022 à 11:53, Etienne LEFAIVRE <mailto:etienne.lefai...@kyxar.fr>> a écrit :


Bonjour la liste,

Je me permets de vous solliciter pour avoir votre retour 
d’expérience sur la gamme CloudCoreRouter de Mikrotik.
J'ai un bon retour d'expérience sur cette marque pour du petit 
routeur à déployer chez le client final.
Sur un modèle comme le RB3011 par exemple, ça tient bien le gigabit 
même avec du firewalling + QOS VOIP pour un coût très raisonnable.


En revanche, je suis pour le moment assez sceptique pour racker du 
Mikrotik en cœur de réseau...
Mon besoin est de remplacer un ASR-1002 qui est actuellement 
utilisé comme routeur de bordure.
Ce routeur s'occupe du BGP pour gérer 2 fournisseurs de transit + 
peering. 2 ports 10G utilisés.
Il n'a que 4Go de RAM (2Go dispo pour IOSD) et commence donc à 
montrer ses limites pour BGP...
Je suis séduit sur le papier par le modèle Mikrotik CCR2116-12G-4S+ 
(< 1000€).
Financièrement, l'écart est tellement énorme entre du Cisco broker 
et du Mikrotik tout neuf que le doute s'installe ! (surtout que 
nous doublons l'investissement pour garder du spare au cas où)


Je prends donc avec plaisir vos retours sur cette gamme.
Merci d'avance et bon appétit !

--
Etienne LEFAIVRE
---
Liste de diffusion du FRnOG
http://www.frnog.org/ <http://www.frnog.org/>


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


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



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



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

Re: [FRnOG] [TECH] Retour d'expérience routeur Mikrotik gamme CCR

[Pierre Colombier via frnog]

euh sur ce coup là, je ne suis pas d'accord.

Tous les produits de la gamme "pro" ont une alim 220V intégrée, certains 
une double, d'autre non.



Sur les petit routeurs et switchs, milieu de gamme quasiment tout est 
compatible POE passif 24V ou utilise une alim DC 24V séparée. voir les 
deux pour la redondance mais la redondance n'est probablement pas 
l'objectif sur cette gamme de produits.


Les produits POE 802.xx "af" ou "at" (souvent des AP wifi) sont tous 
compatibles avec du 24V passif.


Il n'y a que les tout petites box qui sont parfois en micro-usb (5V) ce 
qui est finalement pas mal pour faire de boites à VPN qu'on alimente 
avec le port usb de son ordi.



Alors ok, c'est un peu diversifié mais "délire complet" ça me semble 
très très excessif.






On 07/10/2022 12:52, David Ponzone wrote:

Oui, encore un truc qui va pas chez MK: la non-cohérence des équipements niveau 
alim….

C’est du délire complet (un coup AC/AC, rarement hotplug, parfois POE-in/DC, 
parfois les 3, à croire que ça les éclate).

Donc pour Etienne, ça serait plutôt:

CCR2216-1G-12XS-2XQ (les ports 25G semblent supporter le 10G)
CCR1072-1G-8S+

C’est marrant, dès qu’il y a 16GB de RAM et des alims hotplug, le prix tape un 
peu plus :)
Ca reste raisonnable par rapport à l’équivalent Cisco ou Juniper en broke 
(difficile d’être à moins de 10k€).


Le 7 oct. 2022 à 12:20, Samuel Chesnel  a écrit :

Lo,

+1 pour le soft.
+ le Hardware, alimentation pas simple à remplacer en cas de défaillance !

Le ven. 7 oct. 2022 à 12:09, David Ponzone mailto:david.ponz...@gmail.com>> a écrit :
Il y a eu un long échange à ce sujet sur la liste y a pas très longtemps il me 
semble, faut vérifier l’archive.
C’est de toute façon un sujet récurrent.

Niveau HW, le matos est fiable (je parle pour les anciens modèles, personne a 
de recul sur le CCR2116).
Après, le problème c’est le software.
Il y a 2 aspects:
-le CLI: personnellement, je ne me vois pas gérer des transits/peerings avec 
Router OS, j’ai bien trop d’habitudes en Cisco-like ou Juniper-like.
-le CPU: c’est plus compliqué. Jusqu’à la R6, BGP n’était pas multi-threadé, et 
ça devait changer en R7. Le problème que j’ai avec la R7, c’est que pour une 
MAJ qu’on a attendue littéralement 5 ans (plus ?), je trouve que sa sortie a 
été un total non-évènement et je ne sais pas quoi en penser. Au final, je ne 
m’y suis pas intéressé, donc je sais pas trop de quoi elle est vraiment 
capable. J’ai mis à jour un Mikrotik en R7 en tout, sur un bon paquet. Ca en 
dit long sur mon niveau de confiance :)

A mon avis, tu peux faire un truc.
Tu mets un RB3011 en R6 avec 2 sessions BGP vers ton ASR1002, en lui envoyant 
le max de préfixes qu’il peut tenir avec son petit 1Go de RAM.
Tu fais des clear, tu regardes combien de temps il met à recevoir les préfixes 
et converger (donc tu regardes à combien le CPU monte et quand il revient à la 
normale).
Ensuite tu le passes en R7, et tu compares.


Le 7 oct. 2022 à 11:53, Etienne LEFAIVRE mailto:etienne.lefai...@kyxar.fr>> a écrit :

Bonjour la liste,

Je me permets de vous solliciter pour avoir votre retour d’expérience sur la 
gamme CloudCoreRouter de Mikrotik.
J'ai un bon retour d'expérience sur cette marque pour du petit routeur à 
déployer chez le client final.
Sur un modèle comme le RB3011 par exemple, ça tient bien le gigabit même avec 
du firewalling + QOS VOIP pour un coût très raisonnable.

En revanche, je suis pour le moment assez sceptique pour racker du Mikrotik en 
cœur de réseau...
Mon besoin est de remplacer un ASR-1002 qui est actuellement utilisé comme 
routeur de bordure.
Ce routeur s'occupe du BGP pour gérer 2 fournisseurs de transit + peering. 2 
ports 10G utilisés.
Il n'a que 4Go de RAM (2Go dispo pour IOSD) et commence donc à montrer ses 
limites pour BGP...
Je suis séduit sur le papier par le modèle Mikrotik CCR2116-12G-4S+ (< 1000€).
Financièrement, l'écart est tellement énorme entre du Cisco broker et du 
Mikrotik tout neuf que le doute s'installe ! (surtout que nous doublons 
l'investissement pour garder du spare au cas où)

Je prends donc avec plaisir vos retours sur cette gamme.
Merci d'avance et bon appétit !

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


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


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



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

Re: [FRnOG] [TECH] (résolu) fin du support de ssh-rsa signé avec sha-1 dans RouterOs 7.4

[Pierre Colombier via frnog]

Hello Vincent, et merci pour ton aide.


Non, je ne sais pas quelle est le serveur ssh utilisé sur mikrotik.

C'est un système fermé.

mais vu qu'il arrivent à faire rentrer tout ça dans 16Mo, je ne serait 
pas étonné que ça soit un truc minimaliste dans le genre de dropbear.



Mais par contre j'ai fini par trouver le problème et ça n'a rien à voir 
avec l'algo de signature.


Je me suis fait polluer le cerveau par le message dans le log qui 
parlait de rsa-sha2-sha256 mais en effet, l'algo de signature ne semble 
pas être dans le blob publique.


Et pour tout dire, j'aime mieux ça parce que c'était perturbant.


En fait, le problème vennait du fait que mon ancienne clé avait une 
longueur peu commune de 3874 bits. ( c'était fait exprès suite à 
CVE-2008-0166 )


J'ai régénéré 3 nouvelles clés

ssh-keygen -t rsa -b 2048

ssh-keygen -t rsa -b 3874

ssh-keygen -t rsa -b 4096

en ros 7.2.3 les 3 fonctionnent.

En ros 7.4 Les 2048 et 4096 passent, mais la 3874 échoue avec le même 
message que j'ai posté précédemment  "ssh,error signature differs for user"



Donc, c'est bien un problème avec ros et qui relève plutot du bug que 
d'ajout/retrait de fonctionnalités décrites dans leur changelog


v7.4

*) ssh - disable ssh-rsa when strong-crypto=yes and use rsa-sha2-sha256;
*) ssh - fixed host key generation (introduced in v7.3);
*) ssh - implemented "server-sig-algs" extension in order to improve 
rsa-sha2-sha256 support;


v7.3

*) ssh - added AES-GCM cipher support;
*) ssh - fail non-interactive client after first invalid password;
*) ssh - fixed corrupt host key automatic regeneration;
*) ssh - fixed private key usage after downgrade;
*) ssh - removed DSA public key authentication support;




On 30/08/2022 08:17, Vincent Bernat wrote:

On 2022-08-30 03:21, Pierre Colombier via frnog wrote:

Je ne suis pas sur d'avoir bien tout compris mais il semble bien que 
le fameux algo de hash sha1 ou sha2-256 ou autre soit inclus dans le 
"rsa_signature_blob"


Cette partie est utilisée dans le protocole SSH lors de 
l'authentification, pas dans le format de la clef.



aug/30 01:23:26 ssh,debug pki algorithm: ssh-rsa


Ca ressemble pas aux messages de debug de OpenSSH. C'est un OpenSSH 
qui tourne sur les Mikrotik ? Elle fait quelle taille cette vieille 
clef ? Les releases notes de la 7.4 disent que le change ne concerne 
que ceux qui ont activé strong-crypto=yes, est-ce ton cas ?



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



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

Re: [FRnOG] [TECH] fin du support de ssh-rsa signé avec sha-1 dans RouterOs 7.4

[Pierre Colombier via frnog]

Bonsoir Vincent,

J'ai regardé (vite fait) le RFC4253 et justement il fait référence au rfc3447

https://datatracker.ietf.org/doc/html/rfc3447#section-8.2

Also, in the encoding
   method EMSA-PKCS1-v1_5, a hash function identifier is embedded in the
   encoding.  Because of this feature, an adversary trying to find a
   message with the same signature as a previously signed message must
   find collisions of the particular hash function being used; attacking
   a different hash function than the one selected by the signer is not
   useful to the adversary.

https://datatracker.ietf.org/doc/html/rfc2437#section-9.2.1

Je ne suis pas sur d'avoir bien tout compris mais il semble bien que le fameux algo de 
hash sha1 ou sha2-256 ou autre soit inclus dans le "rsa_signature_blob"


Bref, comme tout ce qui a l'air simple, en fait, c'est hyper compliqué


Quoi qu'il en soit, le présent fil de discussion est motivé par le problème 
suivant :

J'ai une clé rsa de longue date utilisée sur une foule d'équipements mikrotik, 
et ça marche très bien jusqu'a ROS v7.2.3

aug/30 01:23:26 ssh,debug agreed on:
diffie-hellman-group-exchange-sha256
rsa-sha2-256
aes128-ctr aes128-ctr
hmac-sha1 hmac-sha1
none none
aug/30 01:23:26 ssh,debug auth req: pierre ssh-connection publickey
aug/30 01:23:26 ssh,debug auth retry: 1
aug/30 01:23:26 ssh,debug pki algorithm: ssh-rsa
aug/30 01:23:26 ssh,info publickey accepted for user: pierre

Après update en v7.4, ça ne marche plus
aug/30 01:38:01 ssh,debug agreed on:
diffie-hellman-group-exchange-sha256,
rsa-sha2-256,
aes128-ctr, aes128-ctr,
hmac-sha1, hmac-sha1,
none, none
aug/30 01:38:02 ssh,debug auth req: pierre ssh-connection publickey
aug/30 01:38:02 ssh,debug auth retry: 1
aug/30 01:38:02 ssh,error signature differs for user: pierre

Après génération d'une nouvelle clé et sans changer aucune autre option tant 
sur le serveur que sur le client

aug/30 01:42:41 ssh,debug agreed on:
    diffie-hellman-group-exchange-sha256,
    rsa-sha2-256,
    aes128-ctr, aes128-ctr,
    hmac-sha1, hmac-sha1,
    none, none

aug/30 01:42:41 ssh,debug auth req: pierre ssh-connection publickey
aug/30 01:42:41 ssh,debug auth retry: 1
aug/30 01:42:41 ssh,debug pki algorithm: rsa-sha2-256
aug/30 01:42:41 ssh,info publickey accepted for user: pierre


Donc, si par exemple on a une clé de ce type là.
Si on a tout desactivé sauf ssh
et si on a laisse
/ip ssh set always-allow-password-login=no
qui est la valeur par défaut

et bien après upgrade en RoS 7.4, on est beuzeuh ! c'est bon pour un factory 
reset !



On 30/08/2022 00:02, Vincent Bernat wrote:

On 2022-08-29 23:13, Pierre Colombier via frnog wrote:

En d'autres termes, quand il y a bien longtemps, sur une debian 8 far 
far away, j'ai fait un


ssh-keygen -t rsa -b 4096

ou bien aujourd'hui sur une debian 11

ssh-keygen -t rsa-sha2-256 -b 4096


C'est exactement pareil que -t rsa ou -t ssh-rsa car une clef RSA, ce 
sont deux nombres. Il n'y a pas de hash. Le -t rsa-sha2-256 est 
utilisé quand on signe des clefs avec un certificat.


je crée toujours une clé rsa de 4096 bits, j'ai bien toujours un 
fichier id_rsa.pub qui a le même format et commence par "ssh-rsa", 
mais par contre, il y a bien une différence, car quand bien même le 
client ssh serait récent, la première a cessé d'être acceptée par les 
serveur ssh récents, alors que la seconde fonctionne bien.


donc, le "public key blob" quand bien même il ne change pas de 
format, embarque bien quelque chose qui est basé sur un hash sha1 ou 
sha256 (ou autre).


Refait la même chose avec -t ssh-rsa et cela fonctionnera aussi. Ce 
n'est pas pour ça que ta clef n'est plus acceptée. C'est soit qu'elle 
est trop petite, soit que ce n'est pas elle qui est dans le known hosts.
Ou alors, le "blob" contient juste la clé publique + une étiquette 
qui dit quel algo de hash on est sensé employer et dans ce cas 
j'aurais bien aimé modifier mon fichier .pub pour employer le nouvel 
algo tout en gardant la même clé. ça me rendrait la migration 
beaucoup plus simple.


Nope. Le format est dans la RFC 4253. Ce sont deux nombres encodés.
https://datatracker.ietf.org/doc/html/rfc4253#section-6.6


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

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

Re: [FRnOG] [TECH] fin du support de ssh-rsa signé avec sha-1

[Pierre Colombier via frnog]

Bonsoir François, et Emmanuel


Merci pour vos réponses.

Et merci pour le lien sympa, mais qu'en fait, j'avais déjà parcouru.


A une époque qui commence à me paraitre lointaine, j'avais fait du RSA 
sur papier et avec des petit nombres en cours d'arithmétique.


Donc, même si ça date, je vois encore assez bien ce que c'est.


Je suis bien d'accord que RSA n'est pas utilisé pour le gros de la data 
mais sert à échanger les clés éphémères d'algos comme AES ou Blowfish et 
ainsi établir le canal chiffré.


Il me semblait cependant que c'était plus pour des questions de 
performances que de sécurité que RSA n'était employé qu'avec des tout 
petit volumes. Mais en fait, peu importe...


Si je vois bien l'utilité de signer des choses avec un algo de hash pour 
sécuriser la session, ou authentifier des paquets, etc... Le choix de 
l'algo de hashage me semble tout de même relever des négociations entre 
client et serveur à l'établissement de la session et je ne vois toujours 
pas en quoi ça caractériserait la clé et en ferait un type de clé à part 
entière.


En d'autres termes, quand il y a bien longtemps, sur une debian 8 far 
far away, j'ai fait un


ssh-keygen -t rsa -b 4096

ou bien aujourd'hui sur une debian 11

ssh-keygen -t rsa-sha2-256 -b 4096

je crée toujours une clé rsa de 4096 bits, j'ai bien toujours un fichier 
id_rsa.pub qui a le même format et commence par "ssh-rsa", mais par 
contre, il y a bien une différence, car quand bien même le client ssh 
serait récent, la première a cessé d'être acceptée par les serveur ssh 
récents, alors que la seconde fonctionne bien.


donc, le "public key blob" quand bien même il ne change pas de format, 
embarque bien quelque chose qui est basé sur un hash sha1 ou sha256 (ou 
autre).


Et c'est bien de cela que je ne comprends (toujours pas) l'utilité.

Ou alors, le "blob" contient juste la clé publique + une étiquette qui 
dit quel algo de hash on est sensé employer et dans ce cas j'aurais bien 
aimé modifier mon fichier .pub pour employer le nouvel algo tout en 
gardant la même clé. ça me rendrait la migration beaucoup plus simple.




On 29/08/2022 20:58, Francois Romieu wrote:

Ta clef privée RSA ne doit pas être employée pour chiffrer *directement* des
données [...]

On 29/08/2022 21:56, Emmanuel DECAEN wrote:

Bonsoir,

Une petite explication sympa:

https://levelup.gitconnected.com/demystifying-ssh-rsa-in-openssh-deprecation-notice-22feb1b52acd

Bonne lecture.
--
*Emmanuel DECAEN*


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

Re: [FRnOG] [TECH] fin du support de ssh-rsa signé avec sha-1

[Pierre Colombier via frnog]

Bonsoir vincent,


Oui, il y a une homonymie qui prête à confusion.

>"ssh-rsa" keys are capable of signing using "rsa-sha2-256" (RSA/SHA256),
>"rsa-sha2-512" (RSA/SHA512) and "ssh-rsa" (RSA/SHA1).

le nom "ssh-rsa" est employé 2 fois dans des contextes différents (et 
d'ailleurs WTF ???)


Mon problème par contre, n'est pas de se connecter à un vieux serveur 
mais au contraire à un serveur trop moderne qui suite à mise à jour se 
met subitement à reffuser les ancienne clés, et sur lequel on a pas la 
main parce-qu'il est propriétaire (mikrotik est un système fermé)



J'entends bien que le *format* "ssh-rsa" n'est pas déprécié.

D'ailleurs ma nouvelle clé publique type "rsa-sha2-256" commence bien 
par "ssh-rsa B3NzaC1yc2EAA.."


Ma question "académique" est que je ne comprends pas d'où vient ce 
besoin d'une signature/hash ? que ce soit md5, sha1, sha256 ou autre, en 
quoi l'algo rsa seul n'est-il pas suffisant ?



J'ai bien déjà googlé la question mais pour le moment je n'ai pas trouvé 
d'explications claires.


La réponse est sûrement dans les RFC, mais j'avoue que j'ai pas 
tellement envie de me taper des heures de lecture juste pour ça.


D'où le fait que je la pose ici, au cas ou un geek barbu pouvait 
m'éclairer en quelques phrases et quelques liens.





On 29/08/2022 18:08, Vincent Bernat wrote:

On 2022-08-29 15:25, Pierre Colombier via frnog wrote:


du coup, si tous les usagers ont des clées rsa installées et si ssh est
la seule façon d'administrer le routeur, et bien on perds toute 
possibilité d'accès

après la mise à jour.


Ce ne sont pas les clefs "ssh-rsa", c'est l'algo de signature à clef 
publique ssh-rsa qui est désactivé par défaut. Pour se connecter à un 
vieux serveur qui n'accepte pas d'algo plus moderne, on peut toujours 
utiliser "-o HostKeyAlgorithms=+ssh-rsa" pour le réactiver.


Le format de clef ssh-rsa n'est pas prévu d'être déprécié. Il n'y a 
pas d'utilisation de SHA1 dans les clefs ssh-rsa.



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



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

Re: [FRnOG] [TECH] fin du support de ssh-rsa signé avec sha-1

[Pierre Colombier via frnog]

ça n'était pas ma question.


Oui, ma clé est super-ancienne.

Oui, c'est très facile d'en faire une nouvelle et cependant ça m'ennuie 
d'en changer car elle est installée sur une foule de machine et je suis 
à peu près certain d'en oublier.


Du coup je vais quand même devoir garder la vieille dans un coin

en passant ed25519 n'est pas accepté sur mikrotik


Et ma question c'est justement cette histoire de signature (sha1 ou 
autre) :


Vu que c'est pas un truc avec tiers de confiance, pourquoi un clé 
publique a-t-elle besoin d'être signée par quoi que se soit ?




On 29/08/2022 17:22, Laurent S. via frnog wrote:

Openssh 8.7 est sorti le 2021-08-20. Les problèmes de SHA1 sont connus depuis 
encore bien plus longtemps.

De ce que je comprend, si ta clé est super ancienne (ssh-rsa en sha1) elle ne 
devrait plus être acceptée, même si elle est dans les ~/.ssh/authorized_keys

Il existe des autres clés RSA faites plus récemment qui vont continuer de 
fonctionner (SHA256, SHA512).

Faire une nouvelle clé est super facile. Perso je conseille une clé elliptique:

ssh-keygen -t ed25519 -C "u...@example.org"

(n'oublie pas de changer le -C)

La partie plus embêtante est de copier ta nouvelle clé publique sur tous les 
serveurs.

Je comprend pas le commentaire sur la signature. Est-ce le fait de signer une 
clé dans un CA? Je n'ai jamais joué avec ça et il me semble que cela se fait 
rarement.

Courage,
Laurent


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



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

[FRnOG] [TECH] fin du support de ssh-rsa signé avec sha-1

[Pierre Colombier via frnog]

Bonjour la liste,

https://www.openssh.com/txt/release-8.7

>In the SSH protocol, the "ssh-rsa" signature scheme uses the SHA-1
>hash algorithm in conjunction with the RSA public key algorithm.
>It is now possible[1] to perform chosen-prefix attacks against the
>SHA-1 algorithm for less than USD$50K.

>Note that the deactivation of "ssh-rsa" signatures does not necessarily
>require cessation of use for RSA keys. In the SSH protocol, keys may be
>capable of signing using multiple algorithms. In particular, "ssh-rsa"
>keys are capable of signing using "rsa-sha2-256" (RSA/SHA256),
>"rsa-sha2-512" (RSA/SHA512) and "ssh-rsa" (RSA/SHA1). Only the last of
>these is being turned off by default.


Parmis les choses que ça peut impacter assez fortement, il y a les 
routeurs mikrotik qui ont par défaut

/ip/ssh set always-allow-password-login=no

du coup, si tous les usagers ont des clées rsa installées et si ssh est
la seule façon d'administrer le routeur, et bien on perds toute 
possibilité d'accès

après la mise à jour.

Bon, je vais devoir me cogner un changement de clé C'est long, mais ça 
se fait...
seulement, voila, pour la "culture", il y a quand même quelque chose que 
je ne comprends pas.


De ce que j'ai toujours cru, RSA est un algo clé-privée/clé publique.
Et à priori, le fichier id_rsa.pub contient la clé publique en question. 
*toute* la clé publique.
Je ne sais pas trop comment elle est encodée, mais c'est bien la même 
chose que l'on met dans .ssh/authorized_keys.


Et pour tout dire, je ne vois pas à quoi ça sert d'avoir en plus une 
signature.
Soit on a la clé privée qui correspond à une clé publique whitelistée et 
alors c'est OK, soit on ne l'a pas.



Ou alors, ça ne fonctionne pas vraiment comme j'ai toujours cru que ça 
fonctionnait.

Quelqu'un peut-il apporter un éclaircissement ?





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

Re: [FRnOG] [TECH] Statping-ng, WTF....

[Pierre Colombier via frnog]

depuis que ça existe, je n'ai jamais rien trouvé d'aussi bien pensé que RRD.

(je parle de fonctionnalités et d'efficacité, parce que le conf en 
notation polonaise..)



tout les autres outils que j'ai essayé ont une approche naïve cumulant 1 
ou plusisurs des défauts suivants :


- le volume de données explose rapidement

- le temps de calcul explose rapidement

- Le système gère mal les donnée manquantes

- Le système gère mal le fait que l'intervale de mesure de soit pas 
parfaitement régulier.



Alors j'ai pas la prétention d'avoir tout essayé.

Et justement. si il y a des suggestions sur des nouveaux trucs sympa.



Le 17/05/2022 à 20:00, Jarod G. via frnog a écrit :

Salut,

Les deux, de mémoire la db n'est jamais vidée automatiquement et 
sqlite quand y a trop de records ça patine sévère.


On 17/05/2022 17:39, David Ponzone wrote:

Je suis le seul à avoir des soucis avec statping-ng ?
Quelques monitoring en place (genre 3 ou 4, toutes les secondes ou 5 
sec), et au bout de quelques jours/semaines, la DB fait 200Mo, et les 
perfs de l’interface web deviennent anémiques à la limite de 
l’inutilisable. Non vraiment inutilisable en fait.

Il y avait déjà ce souci sur l’ancien statping.
Evidemment remettre à zéro la DB règle problème, mais j’ai pas trouvé 
de commande pour purger la DB de ce qui est plus ancien.


Limite de sqlite ou problème inhérent au code de statping-ng ?

Merci


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



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



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

[FRnOG] [TECH] full view ipv6

[Pierre Colombier via frnog]

Bonjour, j'ai des problèmes ipv6 en ce moment,

J'ai 69k préfixes sur un transitaire 146k sur un autre et 56k sur un 
troisième.



j'aimerais savoir combien de préfixes est sensé contenir une full view 
ipv6 en ce moment.







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

Re: [FRnOG] [MISC] IPv6 - Posséder son adresse

[Pierre Colombier via frnog]

J'anticipe peut être trop la question derrière la question mais le 
problème d'un particulier qui aurait son préfixe, c'est qu'il va falloir 
qu'il le fasse annoncer par un FAI et que ça rentre dans le cadres des 
prestations "pro" dont les tarifs n'ont généralement rien à voir avec 
l'offre ftth grand public des 4 grands.


Autant pour une entreprise, c'est pas vraiment un problème. (encore que...)

Mais si le "particulier" c'est juste un geek qui veut sont préfixe à lui 
mais sans avoir de budget derrière, à moins d'avoir quelques potes bien 
placé, ça va coincer...




Le 19/03/2022 à 16:50, Matic Vari a écrit :

Bonjour,

Une petite question naïve, j’avoue ne pas avoir fouillé trop sur le site du
RIPE, mais est-ce qu'un particulier pourrait posséder son adresse IPv6 [1]?

Cdlt,

[1] : abus de langage, je penses ici que ce serait plus un préfixe ou un
range, non?

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



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

Re: [FRnOG] [TECH] Les routeurs dépendent-ils du serveur de licence ?

[Pierre Colombier via frnog]

A la limite, je peux comprendre qu'on paie pour activer des fonctions 
additionnelles ou qu'on re-paie pour avoir des mises à jour. Je trouve 
ça détestable, mais je peux comprendre que ça existe.


Par contre, un truc qui se met en panne passé un délais si il n'a pas pu 
valider sa licence dans le cloud, ca me semble tellement inadmissible 
que j'ai peine à croire que ça se fasse.


C'est quoi la marque du biniou que j'évite de perdre mon temps avec ?



Le 15/03/2022 à 16:08, ic a écrit :

io,


On 14 Mar 2022, at 12:17, Xavier Beaudouin via frnog  wrote:

Sympa... Au bout d'un an... BING !….

et si on recule l’horloge ? :)

++ ic
  




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



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

Re: [FRnOG] [MISC] Implementation des mesures de blocage de contenus chaines TV Russes

[Pierre Colombier via frnog]

Pour ce qui est du bloquage "massif" et basique, bah en gros, YT a déjà 
fait le boulot


Il y a visiblement eu des choses sur le DNS qui ont été évoqué dans un 
autre fil.



Pour les autres, à moins de subitement interdire des technos à la pelle, 
on ne pourra de toute façon pas bloquer le geek qui sait faire des 
tunnels et des vpn pour ne parler que des choses les plus évidentes.


Donc pour ma part, je ne fait rien.

Et en l'absence de consigne claire disant et le "quoi" et le "comment", 
je compte bien continuer.




On 09/03/2022 12:19, r...@icodia.com wrote:

sans même dire que si on doit bloquer toutes les ip qui risquent de faire des 
attaques, il faudrait bloquer
aussi pas mal d'hébergeurs français, US, etc, qui comportent pas mal de 
machines fantômes servant à tous les
botnets de la terre...

Le 09/03/2022 à 12:10, Wallace a écrit :

On a eu des demandes de clients de bloquer les IPs géo de Russie et Biélorussie 
en entrant et sortant de leur
firewall.

Ils n'ont aucun lien avec ces pays et c'est plus vis à vis des risques cyber 
qu'ils veulent éviter que des
actions malveillantes arrivent ou sortent des données de / vers ces pays.

Sinon complètement d'accord à ne rien faire, il y a un cadre légal qui n'est 
pas respecté, on dit de bloquer
sans nous dire quoi / comment, donc D réponse D aussi. Ça me fait penser aux 
sites pour adultes dont l'Etat ne
sait pas comment et donc ne suggère rien qui serait acceptable, ben du coup ils 
n'ont rien fait et vont se
prendre un strike, limite à croire que c'était voulu.


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






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



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

Re: [FRnOG] [TECH] Equipement de protection laser (lunettes de protection)

[Pierre Colombier via frnog]

Salut,

Je plussoie de suivre les recommendantions de la médecine du travail 
toussa toussa.



Méfie toi des équipement de protection qui ne sont pas certifiés du 
genre qu'on trouve à 5€ sur alibaba.


Déjà, zéro assurance en cas de problème mais surtout, sur le plan 
qualité, c'est la roulette russe.


Certains peuvent être excellents, d'autres ne sont au finale qu'une 
protection d'impact joliment colorée.



Cela dit, pour les "jojo la bricole" et ceux qui veulent se la jouer 
cowboys, certains (vieux) APN filtrent mal les infrarouges. Tu film le 
module optique avec, normalement, ça éblouit le capteur ccd (en espérant 
que ça ne le flingue pas tout net si c'est trop puissant). Intercale les 
lunettes, si tu vois encore le spot après, jettes les Note que ce 
genre de test ne garantit pas que ça soit une protection suffisante pour 
regarder le laser bien en face, mais au moins tu élimines les bouses qui 
rassurent sans rien protéger et au final augmentent les risques.


https://pasteboard.co/omTeDzCDj7vd.jpg




On 02/03/2022 01:11, Jeremy wrote:

Salut,

Je te conseille de faire appel à la médecine du travail, le risque 
laser optique est un risque du travail qui doit être pris en compte, y 
compris sur des puissances plus faible, au moins pour faire la 
prévention d'usage (genre ne pas regarder dans un module optique, 
etc...).


Ils connaissent >> en général << les normes, et peuvent d'aiguiller 
sur les EPI à utiliser.


Jérémy


Le 01/03/2022 à 11:31, Radu-Adrian Feurdean a écrit :

Bonjour,

Non, ce n'est pas cotre l'etoile de la mort, ni contre les fusils laser.

Par contre, comme on commence a travailler avec des equipements qui 
peuvent sortir des signaux  allant jusqu'a +20-22 dBm (ca fait deja 
classe 3B), on se pose la question de l'equipement de protection 
(principalement lunettes). On a deja trouve a droite et a gauche des 
lunettes de protection marques "Absorption EP-5" jusqu'a EP-8 (et 
pretendant bien couvrir le spectre concerne : minimum 800-1700 nm), 
mais aucune information sur ce que ca signifient exactement ces 
normes. Juste parfois des references a la norme EN207:2017, gentiment 
disponible aupres des gentils organismes de normalisation pour des 
somme de l'ordre de 120 EUR.


Est-ce que quelqu'un a plus de details sur ce type d'equipement de 
protection, ou sur ce qu'il est necessaire pour se proteger quand on 
travaille avec des equipements atteignant ce niveau de puissance 
(apart "faire gaffe" ou "eteindre avant de travailler") ?


Merci d'avance.
--
R-A.F.


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



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



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

Re: [FRnOG] [TECH] Livebox V4 et VLAN sur switch manageable

[Pierre Colombier via frnog]

Je ne suis pas sur d'avoir bien compris ta conf.

- ton "coeur" c'est un switch splité en 3 qui relie 3 lan sur 3 livebox?

ou bien

- ton "coeur" est un routeur à 4 pattes avec 1 grosse patte switch/lan 
et 3 pattes ptp avec les livebox ?


- autre ?

Dans le premier cas, Vérifies que les livebox ne présentent pas la même 
adresse mac. Ca serait très étonnant mais commence par là.


Dans les autres cas, vérifies plutot les liens (genre autonégociation 
ethernet)





On 24/01/2022 17:36, Jérémy DUQUESNE via frnog wrote:

près avoir effectuer quelques tests : Modification du port sur la box, 
modification du port sur le cœur, modification du RJ45, modification du module 
sur le cœur, redémarrage des équipements et même utilisation d'un switch 
manageable plutôt que le cœur; rien à faire.

Lorsque je me branche sur le cœur j'arrive à atteindre les appareils qui y sont 
connectés mais pas la livebox ni internet, quand je me branche sur la livebox, 
j'arrive bien à atteindre internet et la livebox mais pas les appareils sur le 
réseau. Pour conclure le tout, quand je connecte des appareils sur un petit 
switch non manageable et la livebox, là tout communique ensemble. C'est pour 
cela que j'en suis arrivé à soupçonner un défaut de communication avec des 
équipements manageable et des VLAN.



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

Re: [FRnOG] [MISC] Smart SFP: mais qu'est-ce qu'on ferait avec?

[Pierre Colombier via frnog]

miner du bitcoin évidemment ;) !

On 19/01/2022 17:28, Pierre LANCASTRE wrote:
quid du host intégré qui plante et qui tourne à fond, sfp qui chauffe, 
surconso électrique [...] A voir ce qu ils en feront :)



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

Re: [FRnOG] [MISC] Smart SFP: mais qu'est-ce qu'on ferait avec?

[Pierre Colombier via frnog]

Oh, y'a quand même des usages envisageables...

faut voir le prix du truc mais ça peut être pas mal comme CPE.


On 19/01/2022 15:54, Alain Iltchev wrote:

Bonjour,

Un reflécteur TWAMP (Light) DIY , déjà fait par certaines boites :
https://www.smartsfp.com/documents/TWAMP_productbrief.pdf
https://creanord.com/products/pulsensor-appliance/ -> PULSensor SFP 200.
https://www.viavisolutions.com/en-us/products/fusion-jmep -> Chez Viavi,
anciennement JDSU

Alain Iltchev



Le mer. 19 janv. 2022 à 15:36, David Ponzone  a
écrit :


Ohhh le beau joujou à DPI!


Le 19 janv. 2022 à 15:17, Remi Desgrange 

a écrit :

Essayons de détendre un peu tout le monde cette aprèm avec quelque chose

de

sérieux, mais léger.
Des gens font des SFP avec Linux dedans :
https://blog.benjojo.co.uk/post/smart-sfp-linux-inside
je ne sais pas si c'est récent, je ne sais pas si c'est en prod, mais je
vois difficilement ce qu'on pourrait faire d'utile avec ça dans un réseau
opérateur. De la protection DDOS encore plus edge que edge ?

À vos suggestions les plus folles :-)

--
Cordialement, Rémi Desgrange

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


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


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



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

Re: [FRnOG] [TECH] Orange listé sur Spamcop

[Pierre Colombier via frnog]

ouais! c'est dredi

Bon alors quand on se fait lister, il y a généralement une vraie 
raison.. Souvent accidentelle, mais une vraie raison quand même.



Par contre, ceux qui bloquent "à la hache" des AS entiers (voir plus 
grand encore), j'ai tendance à considérer que c'est davantage leur 
problème et celui de leur clients que celui de ceux qui se sont font 
bloquer.


Juste contacter l'usager final et lui préciser qu'il a raté un gros 
contrat parce que son fournisseur de mail (généralement m$) a bloqué des 
mails légitimes, y'en a que ça peut gratter



On 14/01/2022 16:21, Jacques MICHAU via frnog wrote:
les serveurs qui se veulent propres dans les usages se font emmder 
régulièrement par une crise de "j'te bloque parce-que j'ai envie"



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

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

[Pierre Colombier via frnog]

Petit retour sur mon CCR2004.

Contrairement à ce que j'ai pu dire plus haut, en fait si ça fonctionne...


ça fonctionne MAIS, il y a un gros MAIS.


Les filtres automatiquement importés su ros6 ne sont pas performants du 
tout et il faut les réécrire complètement.


en particulier les règles qui ont cette tête là, faut virer !

if (protocol bgp && bgp-as-path-slow-legacy \"65535\")

J'ai actuellement 3 full fiew v4 et v6 + 1 ixp et bah avec zéro-filtre, 
ça s'en sort pas mal.


Enfin "pas mal du tout", c'est pas un monstre de réactivité mais disons 
que sur un essai de quelques heures, ça ne crash pas avant d'avoir fini 
de converger.


Maintenant la question est de savoir si ça va être jouable d'écrire des 
filtres sans trop dégrader la performance.







On 07/12/2021 12:23, François Goudal via frnog wrote:

De mon côté j’ai une paire de 1036 qui tournent sous RouterOS 6 et sur chacun 
d’entre eux j’ai deux full view v4 et deux full view v6 et j’ai un constat 
globalement similaire.
Y’a un coeur CPU qui tourne a 100%, et la convergence prend un peu de temps, 
mais sinon c’est stable, sachant que les débits ne sont pas trop élevés non 
plus.



On 7 Dec 2021, at 10:50, François Laperruque  
wrote:

Oui, t'as essaye de me faire peur ;-)

Nous on a jamais plus de 250 Mbps qui transitent sur ce routeur et pour le 
moment pas de packet loss, par contre 1 CPU toujours entre 80 et 100% de load.
-- FAI associatif [Viviers Fibre]
http://viviers-fibre.net (http://viviers-fibre.net)
https://yunohost.viviers-fibre.net (https://yunohost.viviers-fibre.net)

7 décembre 2021 10:38 "Hugues Voiturier" mailto:hugues-lis...@milkywan.fr?to=%22Hugues%20Voiturier%22%20)>
 a écrit:
Je confirme, deux full ça passe sur la ram du 2004, avec un peu de rab’

Bon, par contre moi j’avais du packet loss à gogo sur tous mes 2004 en DFZ.
Depuis que j’ai mis des Arista, j’ai plus de soucis, étrangement… :)
Hugues Voiturier
Consultant en architecture réseauAS57199
On 7 Dec 2021, at 10:37, François Laperruque mailto:flaperru...@viviers-fibre.net)> wrote:

Re,

1 fullview v4 + 1 fullview v6, ca donne ca...

Uptime  3d 18:44:56
Free Memory  1209.1 MiB
Total Memory  1792.0 MiB
CPU  ARMv7
CPU Count  4
CPU Frequency  1700 MHz
CPU Load  20 %
Free HDD Space  91.8 MiB
Total HDD Size  129.0 MiB
Architecture Name  arm64
Board Name  CCR2004-1G-12S+2XS
Version  6.49.1 (stable)
Build Time  Nov/17/2021 10:06:00
Factory Software  6.48.1

-- FAI associatif [Viviers Fibre]
http://viviers-fibre.net (http://viviers-fibre.net)
https://yunohost.viviers-fibre.net (https://yunohost.viviers-fibre.net)

7 décembre 2021 10:13 "Pierre Colombier via frnog" mailto:frnog@frnog.org)> a écrit:
Salut,

Je te confirme que le CCR2004 marche bien en ros6.

Le problème c'est qu'avec cette version, on a accès qu' à 1.7G ram (sur 4G 
hardware) .

Or, si il n'y a pas assez de ram pour rentrer au minimum 2 full view, ça ne 
sert à rien.

Autant travailler avec une default.

En ros7, pour le moment, c'est l'echec.

Il semble que la "traduction automatique" des filtres de ros6 vers ros7 ne soit 
pas parfaite et que
certains posent des problèmes de perf.

Je vais creuser de ce coté là, mais suis preneur de tout retour d'expérience.

On 07/12/2021 06:56, François Laperruque wrote:
Salut Pierre,

Nous avons installé notre 1er CCR2004-1G-12X-2XS, vendredi dernier à TLS00 et 
jusqu'ici pas de
souci.
J'ai pas fait de tests chrono en main mais la full v6 proposée par Fullsave est 
ingurgitée en 20s
et la v4, prend moins
d'une minute.
Le CCR2004 tourne en v6.49.1.
Pour le moment, il est très stable.

J'attends avec impatience les RS toulousains et parisens de France-IX, 
maintenant...

A+

-- FAI associatif [Viviers Fibre]
http://viviers-fibre.net (http://viviers-fibre.net)
https://yunohost.viviers-fibre.net (https://yunohost.viviers-fibre.net)

7 décembre 2021 03:27 "Pierre Colombier via frnog" mailto:frnog@frnog.org)> a écrit:
C'est pas que la peinture est fraiche c'est que c'est pas fini de peindre !

Je viens de passer une journée à tester la v7.1 sur un CCR2004...

et bien c'est pas gagné parce qu'en première approche, non seulement c'est pas 
mieux qu'avec ros6.
mais c'est largement pire.

Pire au sens ou avec ros6, ça rame beaucoup mais ça finit par y arriver, alors 
qu'avec le 7, ça
merdouille tant que ça peut.

Les connexions se cassent, ya des process qui plantent, les stats s'actualisent 
quand elles
veulent...

beurk !

Alors il se peut que je passe à coté d'une option insispensable qui règle tous 
les problèmes, mais
pour le moment, une unique full-view v4, ça semble déjà trop pour le CCR2004.

la full v6, ça a l'air de mieux passer... C'est pas un modèle de réactivité 
mais au moins ça semble
fonctionner.

Si d'autres ont fait des tests, je suis preneur de leur résultats.

Parce que en l'état, ça ne me semble pas utilisable.

On 05/12/2021 21:59, Hugues Voiturier wrote:
Peinture fraiche, mai

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

[Pierre Colombier via frnog]

Salut,

Je te confirme que le CCR2004 marche bien en ros6.

Le problème c'est qu'avec cette version, on a accès qu' à 1.7G ram (sur 
4G hardware) .


Or, si il n'y a pas assez de ram pour rentrer au minimum 2 full view, ça 
ne sert à rien.


Autant travailler avec une default.


En ros7, pour le moment, c'est l'echec.

Il semble que la "traduction automatique" des filtres de ros6 vers ros7 
ne soit pas parfaite et que certains posent des problèmes de perf.


Je vais creuser de ce coté là, mais suis preneur de tout retour 
d'expérience.





On 07/12/2021 06:56, François Laperruque wrote:

Salut Pierre,

Nous avons installé notre 1er CCR2004-1G-12X-2XS, vendredi dernier à TLS00 et 
jusqu'ici pas de souci.
J'ai pas fait de tests chrono en main mais la full v6 proposée par Fullsave est 
ingurgitée en 20s et la v4, prend moins
d'une minute.
Le CCR2004 tourne en v6.49.1.
Pour le moment, il est très stable.

J'attends avec impatience les RS toulousains et parisens de France-IX, 
maintenant...

A+

-- FAI associatif [Viviers Fibre]
http://viviers-fibre.net
https://yunohost.viviers-fibre.net

7 décembre 2021 03:27 "Pierre Colombier via frnog"  a écrit:


C'est pas que la peinture est fraiche c'est que c'est pas fini de peindre !

Je viens de passer une journée à tester la v7.1 sur un CCR2004...

et bien c'est pas gagné parce qu'en première approche, non seulement c'est pas 
mieux qu'avec ros6.
mais c'est largement pire.

Pire au sens ou avec ros6, ça rame beaucoup mais ça finit par y arriver, alors 
qu'avec le 7, ça
merdouille tant que ça peut.

Les connexions se cassent, ya des process qui plantent, les stats s'actualisent 
quand elles
veulent...

beurk !

Alors il se peut que je passe à coté d'une option insispensable qui règle tous 
les problèmes, mais
pour le moment, une unique full-view v4, ça semble déjà trop pour le CCR2004.

la full v6, ça a l'air de mieux passer... C'est pas un modèle de réactivité 
mais au moins ça semble
fonctionner.

Si d'autres ont fait des tests, je suis preneur de leur résultats.

Parce que en l'état, ça ne me semble pas utilisable.

On 05/12/2021 21:59, Hugues Voiturier wrote:


Peinture fraiche, mais ça commence doucement a sentir la fin pour RouterOS6 là, 
la nouvelle
“testing” est une v7 pour la première fois.

Pour moi, encore une mineure de RouterOS6 et ils passent tout en v7. D’ailleurs 
les nouveaux
produits sortent en v7.
Amis opérateurs, il est temps de faire un lab et de commencer à apprendre la 
nouvelle CLI de la v7
;)

Hugues Voiturier
Consultant en architecture réseau
AS57199


On 5 Dec 2021, at 21:49, ALONSO Marc via frnog  wrote:

Bonsoir,

A ce jour pas de BFD implémenté et BGP en VRF ça ne fonctionne pas … ROS 7.x 
prometteur mais encore
« peinture fraîche »….

/ALONSO Marc

Le 2 déc. 2021 à 16:19, Hugues Voiturier  a écrit :

Ils annoncent une convergence bgp 6x plus rapide … avec ROS 7.
De ce que j’ai testé, ça ne sait toujours pas gérer intelligemment un scénario 
de flap, ou il faut
retirer puis insérer 800k routes.
Du coup, tu as toujours des temps de convergence qui se comptent en dizaines de 
minutes :(

Hugues Voiturier
Consultant en architecture réseau
AS57199

On 2 Dec 2021, at 16:10, Mickael Monsieur  wrote:

Bonjour

Vous avez vu passer la newsletter MikroTik avec CCR2116-12G-4S+ ? (Prévu pour 
fin février)

Ils annoncent une convergence bgp 6x plus rapide … avec ROS 7.

On dirait que tout s’accélère pour la sortie de ros 7.x (sortie d’une 7.1 en 
testing aujourd’hui)

Je me demande quand même qui convergera le plus vite sous ros7 entre un arm sur 
ccr2116 ou du
tilera sur 1072…

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

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

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

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

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


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



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

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

[Pierre Colombier via frnog]

C'est pas que la peinture est fraiche c'est que c'est pas fini de peindre !


Je viens de passer une journée à tester la v7.1 sur un CCR2004...

et bien c'est pas gagné parce qu'en première approche, non seulement 
c'est pas mieux qu'avec ros6. mais c'est largement pire.


Pire au sens ou avec ros6, ça rame beaucoup mais ça finit par y arriver, 
alors qu'avec le 7, ça merdouille tant que ça peut.


Les connexions se cassent, ya des process qui plantent, les stats 
s'actualisent quand elles veulent...


beurk !


Alors il se peut que je passe à coté d'une option insispensable qui 
règle tous les problèmes, mais pour le moment, une unique full-view v4, 
ça semble déjà trop pour le CCR2004.


la full v6, ça a l'air de mieux passer... C'est pas un modèle de 
réactivité mais au moins ça semble fonctionner.



Si d'autres ont fait des tests, je suis preneur de leur résultats.

Parce que en l'état, ça ne me semble pas utilisable.




On 05/12/2021 21:59, Hugues Voiturier wrote:

Peinture fraiche, mais ça commence doucement a sentir la fin pour RouterOS6 là, 
la nouvelle “testing” est une v7 pour la première fois.

Pour moi, encore une mineure de RouterOS6 et ils passent tout en v7. D’ailleurs 
les nouveaux produits sortent en v7.
Amis opérateurs, il est temps de faire un lab et de commencer à apprendre la 
nouvelle CLI de la v7 ;)


Hugues Voiturier
Consultant en architecture réseau
AS57199


On 5 Dec 2021, at 21:49, ALONSO Marc via frnog  wrote:

Bonsoir,

A ce jour pas de BFD implémenté et BGP en VRF ça ne fonctionne pas …  ROS 7.x 
prometteur mais encore « peinture fraîche »….

/ALONSO Marc


Le 2 déc. 2021 à 16:19, Hugues Voiturier  a écrit :



Ils annoncent une convergence bgp 6x plus rapide … avec ROS 7.

De ce que j’ai testé, ça ne sait toujours pas gérer intelligemment un scénario 
de flap, ou il faut retirer puis insérer 800k routes.
Du coup, tu as toujours des temps de convergence qui se comptent en dizaines de 
minutes :(

Hugues Voiturier
Consultant en architecture réseau
AS57199


On 2 Dec 2021, at 16:10, Mickael Monsieur  wrote:

Bonjour

Vous avez vu passer la newsletter MikroTik avec CCR2116-12G-4S+ ? (Prévu pour 
fin février)

Ils annoncent une convergence bgp 6x plus rapide … avec ROS 7.

On dirait que tout s’accélère pour la sortie de ros 7.x (sortie d’une 7.1 en 
testing aujourd’hui)

Je me demande quand même qui convergera le plus vite sous ros7 entre un arm sur 
ccr2116 ou du tilera sur 1072…

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


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


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


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



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

Re: [FRnOG] [TECH] notation ipv6

[Pierre Colombier via frnog]

WTF !

sinon, c'est cohérent avec la façon dont prefix::1.1 devient prefix::100:1

mais pouah ! c'est laid!


On 24/11/2021 09:44, Benjamin Abadie via frnog wrote:

On 11/23/21 6:09 PM, Vincent Tondellier via frnog wrote:

il n'existe pas a ma connaissance de format compressé pour les ipv4.


Il me semble que si :

$ ping 1.1
PING 1.1 (1.0.0.1) 56(84) bytes of data.
64 bytes from 1.0.0.1: icmp_seq=1 ttl=52 time=70.9 ms
64 bytes from 1.0.0.1: icmp_seq=2 ttl=52 time=59.2 ms
64 bytes from 1.0.0.1: icmp_seq=3 ttl=52 time=102 ms
^C
--- 1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 59.196/77.383/102.022/18.068 ms


Aucune idée de la standardicité du truc par contre.

:)

Benjamin


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



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

Re: [FRnOG] [TECH] notation ipv6

[Pierre Colombier via frnog]

En fait, j'ai déjà perdu un bon moment à chercher pourquoi ça ne pingait 
pas.


maintenant ce que je voulais savoir c'est si c'est un bug de routeros ou 
bien si c'est une notation contre-intuitive mais tout de même normée.


Il semble qu'on soit dans le premier cas.



On 24/11/2021 09:35, David Ponzone wrote:

Pierre,

Tu devrais pas perdre de temps là-dessus :)
Même l’analyseur syntaxique de ping fait des trucs bizarres en IPv4:

$ ping 1.1.1000
PING 1.1.1000 (1.1.3.232) 56(84) bytes of data.

Après, on peut entrer dan le source pour comprendre.



Le 24 nov. 2021 à 09:31, Pierre Colombier via frnog  a écrit :

Bonjour,

j'avais bien repéré la conversion en hexa.

Par contre, je me serai attendu à ::2a11 ou a ::2a:11

là, y'a une incohérence...



On 23/11/2021 17:58, quentin.leco...@shpv.fr via frnog wrote:

Bonjour,

Il suffit simplement de considérer la conversion décimale en hexadécimal.

42(10) = 2a(16) (devenant 2a00)

17(10) = 11(16)

Bonne soirée.

Quentin Leconte

*De : *frnog-requ...@frnog.org  de la part de Pierre 
Colombier via frnog 
*Date : *mardi, 23 novembre 2021 à 17:49
*À : *frnog-t...@frnog.org 
*Objet : *[FRnOG] [TECH] notation ipv6

Bonjour,

Après avoir saisi une adresse erronée, je viens de me rendre compte sur
un mikrotik que quand on met un point dans une ipv6 ça fait des chose
bizares...

2001::1.1 devient 2001::100:1

2001::42.17 devient 2001::2a00:11

Est-ce que c'est une étrangeté de la notation qui m'aurait échappé ou
bien est-ce qu'il y a un bug ?






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


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



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

Re: [FRnOG] [TECH] notation ipv6

[Pierre Colombier via frnog]

Bonjour,

j'avais bien repéré la conversion en hexa.

Par contre, je me serai attendu à ::2a11 ou a ::2a:11

là, y'a une incohérence...



On 23/11/2021 17:58, quentin.leco...@shpv.fr via frnog wrote:


Bonjour,

Il suffit simplement de considérer la conversion décimale en hexadécimal.

42(10) = 2a(16) (devenant 2a00)

17(10) = 11(16)

Bonne soirée.

Quentin Leconte

*De : *frnog-requ...@frnog.org  de la part de 
Pierre Colombier via frnog 

*Date : *mardi, 23 novembre 2021 à 17:49
*À : *frnog-t...@frnog.org 
*Objet : *[FRnOG] [TECH] notation ipv6

Bonjour,

Après avoir saisi une adresse erronée, je viens de me rendre compte sur
un mikrotik que quand on met un point dans une ipv6 ça fait des chose
bizares...

2001::1.1 devient 2001::100:1

2001::42.17 devient 2001::2a00:11

Est-ce que c'est une étrangeté de la notation qui m'aurait échappé ou
bien est-ce qu'il y a un bug ?






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



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

[FRnOG] [TECH] notation ipv6

[Pierre Colombier via frnog]

Bonjour,

Après avoir saisi une adresse erronée, je viens de me rendre compte sur 
un mikrotik que quand on met un point dans une ipv6 ça fait des chose 
bizares...


2001::1.1 devient 2001::100:1

2001::42.17 devient 2001::2a00:11

Est-ce que c'est une étrangeté de la notation qui m'aurait échappé ou 
bien est-ce qu'il y a un bug ?







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

Re: [FRnOG] Re: [TECH] Tout le monde a bien activé la « QNAME minimisation » ?

[Pierre Colombier via frnog]

Bonjour Stéphane, merci de ta réponse.

On 19/11/2021 17:26, Stephane Bortzmeyer wrote:



alors que c'est quand même le résolveur qui est à la fois le plus
intéressé et le plus en mesure de faire une association entre l'ip
source d'une requête et un nom d'utilisateur.

Mais on peut choisir son résolveur, alors qu'on ne peut pas choisir
les serveurs faiant autorité.


Ok pour les geeks mais en pratique mme Michu ne choisit pas son résolveur...

Soit c'est celui de son FAI, soit c'est le 8.8.8.8 que jean-kévin lui a 
mis..



Alors que de son coté le serveur racine (ou d'un TLD, ou d'un domaine
particulier) ne voit que l'ip source du résolveur.

Et ECS, alors ?


Oups... ça pour le coup c'est une vraie saleté.





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

Re: [FRnOG] [MISC] Dans la série est-ce bien ou pas le draft sur 127/8...

[Pierre Colombier via frnog]

et quand bien même ça se ferait,

vous auriez envie de mettre de la vraie prod sur ce genre la plages ?

pour ma part, même si c'était gratuit (et ça ne le sera pas), je ne suis 
pas chaud.




On 19/11/2021 11:21, Alexis Lameire wrote:

J'ai comme un gout d'IPv4+ dans la gorge.

Je me demande pourquoi.

Alexis

Le jeu. 18 nov. 2021 à 08:26, Xavier Beaudouin via frnog 
a écrit :


Hello,

En jetant un coup d'oeil sur Nanog je suis tombé sur une thread qui parle
de réutiliser
une partie du subnet 127.0.0.0/8 en global unicast :

https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html

Si d'un coté c'est compréhensible d'utiliser ce qui est libre, d'un autre
coté, je vois
une tentative plutôt désespérée de faire durer un protocole qui est voué
a, un jour,
disparaitre...

Sans compter les millions de devices qui ne seront pas upgradés qui ne
peuvent pas
comprendre qu'une partie de 127.0.0.0/8 serait devenu utile...

Bref
Xavier


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


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



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

Re: [FRnOG] [TECH] Tout le monde a bien activé la « QNAME minimisation » ?

[Pierre Colombier via frnog]

Ah bon ? c'est pas comme ça depuis le tout début de DNS ?

Un petit coup de wireshark plus tard, et il semble "à l'oeil" que mon 
résolveur soit déjà conforme à RFC7816.


pourtant, un

rgrep 'qname' /etc/bind

ne renvoie rien


Sinon, autant je trouve que techniquement c'est indiscutablement mieux, 
autant je trouve que pour ce qui est du volet vie privée, c'est quand 
même curieux ce modèle où on fait davantage confiance au résolveur 
qu'aux serveurs racine alors que c'est quand même le résolveur qui est à 
la fois le plus intéressé et le plus en mesure de faire une association 
entre l'ip source d'une requête et un nom d'utilisateur.


Alors que de son coté le serveur racine (ou d'un TLD, ou d'une domaine 
particulier) ne voit que l'ip source du résolveur.


On trouvera sans doute quelques contre-exemples mais dans le cas 
général, j'ai du mal à voir le problème qu'il y a à savoir que 1 des N 
clients de ce FAI a voulu consulter www.train.paris ? et pas seulement 
quelque chose de "paris".



On 19/11/2021 15:11, Stephane Bortzmeyer wrote:

Si vous gérez un résolveur DNS, n'oubliez pas, pour préserver la vie
privée de vos clients, d'activer la minimisation des requêtes (« QNAME
minimisation »). Non, parce que, le RFC de norme (le précédent était
marqué comme expérimental) vient de sortir.

https://www.bortzmeyer.org/9156.html


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



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

Re: [FRnOG] [MISC] RE: arnaque téléphonique, numéro surtaxé

[Pierre Colombier via frnog]

Petite suite trollesque au sujet [TECH] RE: arnaque téléphonique, 
présentation du numéro


renommé en [MISC] pour l'occasion.



C'est pas exactement le même cas que ceux décrits dans les messages 
précédents mais qui concerne le "ping-call" ou les appels qui invitent 
la victime à rappeler un 08xxx pour résoudre un problème aussi grave et 
urgent que fictif.


J'entends bien qu'il pourrait y avoir des solutions techniques de 
bloquage mais ça va être une course de l'épée et du bouclier comme pour 
le spam.


Je crois qu'il y aurait une façon non-technique d'y mettre un terme : 
C'est de faire cesser l'intéret que la pratique présente en commençant 
par bloquer le pognon avant d'attaquer la répression.



Petit brouillon "premier jet" de comment je vois la chose appliquée au 
territoire français mais évidemment transposable à plus grande échelle : 
(commentaires bienvenus)


1) Coté consommateur, les recettes des numéro surtaxés (tous sans 
exception) restent en dépot chez l'opérateur de l'éméteur de l'appel et 
ne sont délivrées à l'opérateur du numéro SVA concerné qu'après purge 
d'un délai permettant la manifestation de plaintes. (une durée de 3 à 6 
mois me semble raisonnable. mon coeur voudrait plus long mais cela 
aurait probablement un vrai impact sur les activités légitimes. On 
pourra toujours avoir un délais augmenté si l'opérateur coté prestataire 
est etranger et connu pour être non-coopératif. )


2) Coté prestataire de service, l'opérateur du numéro SVA ne reverse les 
recettes à son client qu'après purge d'un un délai permettant la 
manifestation des cas frauduleux. (2 à 3 mois me semble indiqués) Auquel 
cas, les fonds sont immédiatement transférés à la caisse de dépôts et 
consignations jusqu'au jugement qui pourra soit les restituer au 
bénéficiaire soit les confisquer. (A noter que la plaignant n'est pas 
remboursé, ce qui devrait éviter les plaintes "intéressées").


3) Automatiser le traitement en renversant la présomption d'innocence : 
On présume la bonne foi de la collectivité des plaignants vs celle du 
professionnel qui, si il est sérieux, n'est pas sensé générer de 
mécontentement statistiquement significatif chez des gens qui sont 
sensés être ses clients.


En cas de nombreux signalements vis à vis du nombre d'appels, 
("nombreux" c'est >2% de signalement), un premier jugement défavorable 
est issu automatiquement avec annulation des transactions récentes en 
(1), confiscation des recettes en (2), et condamnation du propriétaire 
du numéro à verser une amande égale au double du montant qu'il aurait du 
collecter.


4) Le bénéficiaire du numéro surtaxé peut faire appel de cette décision 
automatisée et demander un jugement humain mais uniquement après 
provision des frais impliqués par la procédure.


5a) Si la fraude n'est pas démontrée, tout est restitué et les sources 
de signalements abusifs sont négativement pondérées pour l'avenir.


5b) En revanche, si l'enquête confirme le caractère frauduleux, l'amande 
se monte alors à 100x la somme correspondant à l'ensemble des 
transactions annulées. + les frais de justice. sans que cela éteigne les 
autres responsabilités du fraudeur que cette enquête aurait pu révéler 
(car en général l'arnaque va plus loin que ça). Si le fraudeur est une 
personne morale représentant une organisation de plus de 10 personnes 
(seuil tpe/pme) l'amande est encore doublée, et en cas de récidives de 
la même organisation, on pourra envisager la responsabilité des 
actionnaires et/ou la dissolution/liquidation.


6) Le reste des possibilités d'appels suit le schéma judiciaire classique.

7) Il va de soi que les opérateurs et autorités étrangères risquent de 
ne pas coopérer sur la partie répressive. Auquel cas, on pourrait très 
bien considérer qu'après plusieurs avertissements, leurs "services" 
n'ont plus vocation à être servis sur le territoire sans être relayés 
par une société soumise aux lois et règlements français et dotée d'un 
capital suffisant pour pouvoir faire face aux éventuels problèmes. C'est 
peut-être brutal mais moins que d'emmerder des millions de gens.



Je précise que je ne suis pas juriste, ni même très au courant du 
fonctionnement de ce marché particulier des numéros surtaxés.


C'est juste mon ressenti sur ce qu'il conviendrait de faire pour faire 
cesser les nuisances associées dont vous aurez compris quelle me donnent 
des allergies violentes...


Les commentaires sont les bienvenus.




-Message d'origine-
De : frnog-requ...@frnog.org  De la part de
Nicolas Parpandet
Envoyé : mercredi 10 novembre 2021 19:48
À : frnog 
Objet : [FRnOG] [TECH] arnaque téléphonique, présentation du numéro


Bonjour,

Je suis victime depuis 3 semaines environ d'une arnaque à la
présentation du numéro.

Mon numéro de portable est utilisé pour passer des appels de
prospection, les personnes appelées 9/10 ne répondent pas ou
décrochent et tombent sur du signal vide.
Du coup elles me rappellent en retour, cependant je ne les ai jamais

Re: [FRnOG] [TECH] Horloge atomique rubidium PTP / IEEE-1588 stratum-1 pour la fin du monde

[Pierre Colombier via frnog]

C'est un monde qui m'est étranger, mais est-ce que ça ne rentre pas dans 
le cadre des machines d'un même système où c'est de toute façon 
l'horloge de ce système particulier qui fait foi (qu'il soit synchro ou 
non avec UTC) ?



On 28/10/2021 10:40, Vincent Habchi wrote:

C’était vrai il y a quelques années. Mais maintenant, avec le développement des 
applications et des algorithmes IA de “micro-trading”, il est devenu essentiel 
de dater presque à la microseconde près les transactions financières. Et, 
crois-moi, c’est autrement plus important que les applications scientifiques 
dont tu parles…

Vincent



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

Re: [FRnOG] [TECH] Horloge atomique rubidium PTP / IEEE-1588 stratum-1 pour la fin du monde

[Pierre Colombier via frnog]

Discussion intéressante.

Concernant la synchro, ntp fait déjà des compensations de latence, si il 
n'y a pas trop de gigue et si il n'y a pas s'assymétrie dans les temps 
allé vs retrour, alors la synchro est assez bonne. Très largement 
meilleure que ce que pourrait laisser penser le temps de transmission. 
Sur la durée, on peut aussi compenser la dérive systématique.


Le point important selon moi est qu'une horloge particulière soit 
toujours une fonction monotone croissante. Pour la re-régler on 
l'accélère ou la ralentit un peu (ce qui crée à chaque fois une 
imprécision relative temporaire) mais c'est important qu'elle ne 
revienne jamais en arrière, ce qui reviendrait à dater des évènements 
dans un ordre différent que celui où il se sont réellement produit. 
C'est beaucoup plus important que la précision absolue.


Il y a évidemment des application comme le GPS ou c'est très important 
d'avoir une très bonne synchro. Je ne dis pas le contraire. Mais en 
général, c'est à dire hors recherche scientifique et hors applications 
spatiales, on a peut-être besoin d'une grande précision relative entre 
les machines d'un même système mais rarement besoin de connaitre UTC 
avec plus de quelques ms de précision absolue.


Le problème est que même pour des horloge idéales infiniment justes et 
stables, leur temps physique n'est valable que pour elles mêmes et 
qu'une simple différence d'altitude (donc de champs de gravité) suffit à 
les désynchroniser. Je suis bien conscient qu'on est pas sur les mêmes 
ordres de grandeur en termes de dérive, mais c'est pour bien illustrer 
que ce problème de synchro d'horloges n'est pas uniquement un problème 
de précision des instruments.



On 27/10/2021 23:30, David Ponzone wrote:

Je pense que la question de Pierre était en fait:
Qui détient l’heure exacte précise et comment fait-on pour s’assurer qu’on ne 
le perd pas ?
On resynchronise régulièrement les sources du temps référence entre elles ? 
Mais dans ce cas, comment fait-on pour savoir qu’on synchronise pas avec une 
qui a déjà trop dérivé ?
Ou alors, plus simplement, de temps en temps, toutes les sources sur Terre sont 
mises arbitrairement à la même heure, puisque de toute façon cette heure est 
arbitraire, et la seule chose qui compte, c’est qu’on ait tous la même (sauf 
moi, je suis toujours en retard partout).
Mais même une remise à zéro, ça me perturbe, car aucune communication n’est 
instantanée (sauf celle des sous-espaces dans Star Trek), donc je pige pas 
comment une horloge à Londres et une à Tokyo sont remises à 0 en même temps.



Le 27 oct. 2021 à 23:04, Michel Py via frnog  a écrit :


D'ailleurs, les horloges atomiques, aussi stables soient-elles, on les 
synchronise comment ?

C'est excessivement compliqué, car il faut prendre en compte des facteurs 
relativistes. Par exemple, ou et à quelle distance est la lune, car le champ de 
gravité de la lune (le même que celui qui crée les marées) distord le temps. 
Les satellites sont en mouvement, l'horloge à bord d'un satellite GPS avance 
plus vite que la même horloge sur terre, d'environ 38 microsecondes par jour.

1 microseconde d'erreur dans une horloge de GPS, ferait une erreur de position 
de dizaines de kilomètres. 1 milliseconde, pas la peine d'essayer.



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



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

Re: [FRnOG] [TECH] Horloge atomique rubidium PTP / IEEE-1588 stratum-1 pour la fin du monde

[Pierre Colombier via frnog]

Bien vu!

J'ai calculé avec le rayon pas le diamètre (Et puis en fait, 
c'est le périmètre qui est pertinent)


Enfin, bref, NTP arrive déjà à produire une synchro nettement meilleure 
que ça et les cas où il est vraiment nécessaire d'avoir une précision 
(absolue) supérieure me semblent tout de même assez rares, non ?


D'ailleurs, les horloges atomiques, aussi stables soient-elles, on les 
synchronise comment ?





On 27/10/2021 14:13, David Ponzone wrote:

Ouais mais c’est plutôt 42ms :)


Le 27 oct. 2021 à 14:03, Pierre Colombier via frnog  a écrit :

D'ailleurs, si on considère que la terre fait presque 20 milisecondes-lumière 
de diamètre, est-ce que ça a vraiment du sens d'avoir un temps synchronisé 
tellement plus précis que ça.

On 27/10/2021 10:37, Christophe Desnoyer wrote:

Donc dans le scénario décrit par Michel, NTP continuerait à donner une
référence correcte à quelques ms près.


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


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



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

Re: [FRnOG] [TECH] Horloge atomique rubidium PTP / IEEE-1588 stratum-1 pour la fin du monde

[Pierre Colombier via frnog]

D'ailleurs, si on considère que la terre fait presque 20 milisecondes-lumière 
de diamètre, est-ce que ça a vraiment du sens d'avoir un temps synchronisé 
tellement plus précis que ça.

On 27/10/2021 10:37, Christophe Desnoyer wrote:

Donc dans le scénario décrit par Michel, NTP continuerait à donner une
référence correcte à quelques ms près.



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

Re: [FRnOG] [TECH] libreNMS

[Pierre Colombier via frnog]

+1

On 20/10/2021 16:45, Jarod G. via frnog wrote:
J'ai du mal à comprendre pourquoi c'est pas en stable par défaut, je 
sais que git pull master au lieu de checkout des tags stables c'est à 
la mode mais quand même...






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

Re: [FRnOG] [TECH] libreNMS

[Pierre Colombier via frnog]

J'ai pas eu de pb.

C'est un bug dans introduit puis corrigé dans les MaJ de ces derniers 
jours ou bien c'est un bug plus ancien qui ne se produirait qu'à cette 
date précise ?



On 20/10/2021 12:55, Mickael Monsieur wrote:

Bonjour,

Qui d’autre a vu passer le bug de libreNMS de cette nuit ?

Nous on a eu des Device indiqués comme redémarres alors qu’ils ne l’ont pas 
été, puis toute la nuit / matinée leur uptime dans librenms était farfelu.

On a forcé une mise à jour ce matin et on a reçu les Recover dans la foulée…

Est ce que vous utilisez les daily update? J’ai vu qu’il est possible de passer 
en monthly, peut être à envisager ? Voir désactiver l’auto update totalement …

Mickael


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



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

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

[Pierre Colombier via frnog]

Hello michel, petite réponse à ces deux points


On 07/10/2021 20:40, Michel Py wrote:

Pierre Colombier a écrit :
L'étage d'entrée d'à peu près n'importe quel alim de serveur ou équipement
réseau, c'est basiquement un pont de diodes suivi de gros condensateurs.

Ca, c'était l'alim de grand-papa, le pont de diodes qui redresse et les condos 
qui lissent. Ca fait des lustres que ce n'est plus comme ça, toutes les alims 
modernes sont à découpage.
Je conseille les excellentes vidéos de Stéphane Marty (Deus Ex Silicium) et 
celle-ci en particulier sur le sujet :
https://www.youtube.com/watch?v=o0V5F9aLUM4



je parlais bien des alim à découpage : leur étages d'entrée c'est dans 
l'ordre, filtre EMI, redressement, et lissage de la tension crête soit 
325V pour du 230VAC


(multiplication de la tension efficace par sqrt(2) )

les modèles de base acceptent presque tous du continu, (a vérifier tout 
de même si ça fait pas chier les systèmes de PFC actifs)




et la plupart fonctionnenent avec a peu près n'importe quoi entre 130 et 350V.

C'est vrai, quoi que 350V c'est un peu pousser.


Je n'ai pas été clair, je parlais de la tension crête après redressement

et effectivement 350V on est vraiment dans le haut de la fourchette.



Sinon, J'entends bien l'argument "poulet grillé" et c'est vrai que ça a 
quand même une petite importance 








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

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

[Pierre Colombier via frnog]

je partage ton avis avec le 48V.

C'est dur d'avoir de grosse puissances en basse tension, il faut de la 
forte section etc etc... ça génère d'autres coûts.


Non ma question c'était plutôt pourquoi le datacentre ne distribue pas 
des sources en 325VDC plutôt que du 230VAC.


Mais bon je me répète : y'a peut être une excellente raison à laquelle 
je ne pense pas et auquel cas, je suis preneur d'une explication.




On 07/10/2021 17:01, Julien Escario wrote:

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




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

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

[Pierre Colombier via frnog]

Petite reflexion connexe au sujet propos des onduleurs et autres alims 
redondées.



Pourquoi est-ce qu'en environnement datacentre on reste collé sur le 
système 230V 50Hz ?


OK, le PC classique ou même le serveur d'entrée de gamme a besoin d'une 
alim "normale".


Mais dans un gros DC, quel est intéret ?

L'étage d'entrée d'à peu près n'importe quel alim de serveur ou 
équipement réseau, c'est basiquement un pont de diodes suivi de gros 
condensateurs.


et la plupart fonctionnenent avec a peu près n'importe quoi entre 130 et 
350V.



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 ?



Note : Je suis pas electricien, y'a peut être une excellente raison à 
laquelle je ne pense pas. auquel cas, je suis prenneur d'une explication.







On 06/09/2021 17:16, Michel Py via frnog wrote:

Vincent Duvernet a écrit :
Ce qui laisserait supputer que c'est pour les entreprises plus petites mais 
dans ces
entreprises, personne (du moins dans nos clients) n'a 2 alimentations EDF 
distinctes.

C'est clair, et même quand c'est le cas c'est extrêmement rare que ça soit deux 
sources de haute tension différentes.
A $job[-1] ou on était de très grands consommateurs d'électricité ($1M par mois) on avait 
deux "sub-stations" différentes, une de chaque coté du campus à plusieurs 
centaines de mètres l'une de l'autre, mais c'était la même source de haute tension donc 
au final la même alimentation,


Alors que cela induit que l'ATS ne puisse être connecté qu'à 1 seul onduleur 
sur une
source et sur l'EDF normal sur l'autre source ou bien est "autant-pire" ?

C'est carrément pire, AMHA. J'ai expliqué récemment en détail pourquoi.

Michel.


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



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

Re: [FRnOG] [TECH] [SMTP] outlook.com bloque online.net ?

[Pierre Colombier via frnog]

On 23/08/2021 18:44, David Ponzone wrote:

De toute façon, en sécurité, indiquer à un attaquant qu’un email n’existe pas 
(et donc qu’un autre existe), c’est déjà une faille.


Oui mais dire que le mail a été délivré alors qu'en fait non, me semble 
nettement plus grave.


D'ailleurs, Outlook le fait aussi (code 250 dans mes logs mais jamais 
reçu par le destinataire)


Et quand on leur demande, ils sont infoutus d'expliquer ce qu'il se 
passe parce que ça utilise un service sous-traité...  on crois rêver...


note: (les copié-coller suivants datent d'archives de 2019 et ne sont 
peut être plus actualité mais illustrent bien le problème)


Email filtering is based on many factors, but primarily it's due to mail 
content and recipient interaction with that mail. Because of the 
proprietary nature of SmartScreen® and because SmartScreen® Filter 
technology is always adapting and learning more about what is and isn't 
unwanted mail, it is not possible for us to offer specific advice about 
improving your mail content. However, in general SmartScreen® Filter 
evaluates specific words or characteristics from each e-mail message and 
weights them, based on their likelihood to indicate that a message is 
unwanted or legitimate mail.


Unfortunately, after reviewing the information you provided and in 
compliance with our mail policies, we are unable to offer immediate 
mitigation for your deliverability issue. However, we have some specific 
recommendations for you to consider that can help you to improve 
deliverability over time.


After reviewing your case, I have some additional suggestions for you to 
consider that may assist you in the future with avoiding the 
deliverability issue you've been experiencing.
[...]trucs bidons du genre ne pas mettre le nom de la pilule bleu ciel 
commençant par V dans le titre[...]

I hope you find this information helpful.
Sincerely,


Partant de là, je considère que ce n'est plus un problème d'expéditeur 
méritant que JE consomme de MON temps à résoudre LEURS problèmes.


Et je conseille à qui veut l'entendre de faire appel à n'importe quel 
fournisseur de mail plus sérieux, ou à défaut de vendre son âme à gmail 
qui est sans doute le diable mais qui, au moins, remplis correctement sa 
part du contrat.






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

Re: [FRnOG] Re: Re: [ALERT] Un CDN Down ?

[Pierre Colombier via frnog]

à propos du fil, Il y a moyen de poursuivre la discussion en dehors du 
channel ALERT ?


On 09/06/2021 15:15, Stephane Bortzmeyer wrote:

On Wed, Jun 09, 2021 at 11:24:22AM +,
  Ludovic LACOSTE  wrote
  a message of 37 lines which said:


Et puis d’après l’analyse que j’ai pu lire, le problème est un problème de 
couche 7 (voir 8 , l’interface chaise/clavier, c’est terrible )
Erreur http 503, c’est un problème applicatif, pas réseau. Le DNS
là-dedans …

Personne (à part France Inter) n'a dit que la panne de Fastly était un
problème DNS. Relisez le fil pour voir pourquoi on parlait du DNS.


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



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

Re: [FRnOG] Re: [ALERT] Un CDN Down ?

[Pierre Colombier via frnog]

Je pense que le DNS n'est pas la solution à cause du temps de 
propagation et des caches qui ne respectent pas les ttl courts.


Pour ne pas avoir le problème des caches (y compris celui dans le 
browser du client) , Il faut que ton site soit capable de générer en 
quelques instants des url différentes pointant sur l'autre CDN.



Mais je pense que c'est beaucoup d'efforts pour rien car déjà c'est un 
évènement très rare et qui quand il arrive dure généralement 
potentiellement moins que le temps de détecter le problème et de prendre 
les mesures.


En plus, tu n'est pas à l'abris d'introduire des bugs dans ton propre 
système qui au final aggravera le problème.


On 09/06/2021 11:56, Damien Wetzel wrote:

Bonjour,

En tant que revendeur de la solution, on a un peu souffert hier ;)

Cela m'ammène à la question du multi-CDN, est ce que sa complexité
se justifie pour palier à des problemes comme celui rencontré hier
qui sont quand meme relativement trés rares ?

Est ce que avoir une config de secours sur un autre CDN + un DNS configurable
rapidement avec des TTL courrs ~1min a un sens ?

Vos avis m'interressent.

Cordialement,
Damien


Stephane Bortzmeyer writes:
  > On Tue, Jun 08, 2021 at 12:17:17PM +0200,
  >  Kévin GUERY via frnog  wrote
  >  a message of 14 lines which said:
  >
  > > Apparemment de gros problèmes sur paypal, twitch, amazon et autres
  > > qui sembleraient liés à un problème sur CDN ?
  >
  > Post-mortem de Fastly. Moins bien que ceux de Cloudflare mais meilleur
  > que ceux d'Orange.
  >
  > https://www.fastly.com/blog/summary-of-june-8-outage
  >
  >
  > ---
  > Liste de diffusion du FRnOG
  > http://www.frnog.org/




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

Re: [FRnOG] [TECH] Technos pour du lan bouclé

[Pierre Colombier via frnog]

Si tu as du STP/RSTP fait attention au "diametre" de l'arbre.

La plupart des switches viennent avec des valeurs par défaut assez basses.

Le pire c'est que dans certains cas ça fonctionne quand même très bien 
malgré le dépassement quand on étends le réseau


et puis un jour, c'est quand on coupe un lien "court" qu'on crée une 
boucle par des chemins plus longs que le diamètre.



On 04/06/2021 15:02, BOLLIN, Antonin wrote:

Salut la liste,

Je fais appel aux experts/expertes de dessertes internes pas de boucles locales 
:)
En fait sur site j’ai 32 switch dans 14 armoires différentes.
J’ai des fibres et des modules SFP+ en 10G et 1G qui clignotent et personne cri 
donc j’en déduis que ça fonctionne.

Schéma de principe du réseau :

[..switch..][..switch..] [..switch..]
…….||………|.…….||……..
[..switch..]-[..switch..]--[..switch..]
…….||………|.…….||……..
[..switch..][..switch..] [..switch..]

Donc les lignes double en 10G et les simples traits en 1G.
Donc aujourd’hui j’ai pleins de soucis de lenteurs/collisions/drop etc…  mais 
ça tourne, enfin ça juste marche mais c’est pas foufou.
Ce réseau comporte 23 vlans différents géré par des ACL sur un switch cœur mais 
là n’est pas le soucis. (Je gère presque correctement mes 2100 lignes d’acl)
J’aimerai connaitre les différentes technos de gestion possible pour remplacer 
ou alors agrémenter le stp/rstp etc…
Je demande pas qu’on me fasse le boulot ou qu’on me démarche pour faire de la 
presta je demande ce qu’il existe pour me dire que je ne passe pas à côté d’une 
techno pérenne.
Ce réseau est composé de d’aruba/HP 2530-48G-POE+ et les switchs cœurs sont des 
aruba 5412Rzl2 et 5406Rzl2.
Ma demande est simple qu’est ce qui se fait aujourd’hui qui est maintenable 
aisément ?
J’ai pas 40 heures hebdos de dispo pour gérer ça mais je peux dégager du temps 
pour la mise en place.
Est-ce que le bullshit commercial des logiciels de gestion est avéré et utile 
au quotidien ?
Le besoin est simple il faut que ça continue à tourner même si on coupe la 
boucle à un endroit.
Donc je suis tout ouïe pour les proposition car pour le moment à chaque fois on 
a voulu me vendre des suites logicielles ce qui ne m’ intéresse pas, sauf si 
vous me dites que c’est indispensable…
Merci d’avance pour les propositions.
Je vous souhaite un agréable week-end
Bon courage pour ceux/celles qui sont d’astreinte.
Antonin B.

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


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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Pierre Colombier via frnog]

J'attends avec impatience le syndrome de la poule et de l'oeuf.

Quand le déploiement automatisé du "software defined" reposera sur 
lui-même, et qu'il faudra reseter l'ensemble parce que la manager s'est 
fait hacker, ça promet d'être un spectacle amusant...




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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Pierre Colombier via frnog]

Hello,

Comment vous employez Ansible pour du matos réseau ?

J'ai essayé et 'ai trouvé que c'était la misère...

Ansible sans interpréteur python sur la cible ou sans module bien léché, 
comment dire Autant faire des scripts en bash



On 20/05/2021 13:12, David Ponzone wrote:

Ah Cécile n’ayant pas précisé, j’ai effectivement raccourci à la partie la plus 
visible du SDN.

Si on élargit au coeur de réseau, on reste dans un bon bullshit non ?
Des confs de routeurs poussées par Ansible, c’est du SDN ou pas ?



Le 20 mai 2021 à 13:09, Hugues Voiturier  a écrit :


Sans parler des risques que sous prétexte qu’on fait du « SDN », on met 
n’importe quoi comme liaisons en dessous, parce que le SDN est « agnostique » 
des technos utilisées.

C’est pas plutôt SD-WAN ça ?



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



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

Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?

[Pierre Colombier via frnog]

J'avoue que je n'ai toujours pas compris ce dont il s'agissait.

Je veux dire précisément, qu'est-ce qu'il reste une fois on a enlevé le 
vernis commercial ?



Selon ce qu'on entends par ce mot, soit c'est une coquille vide et ça 
sert pas à grand chose,


soit c'est une boite noire magique qui fait tout automagiquement et 
c'est donc casse-gueule : Quels leviers reste-t-il quand la magie 
n'opère pas ?






On 20/05/2021 12:54, Cécile MORANGE wrote:
Hello la liste ! Je commence à me renseigner sur le SDN et je me suis 
dit que ce serait sympa d'écrire un article sur mon blog 
(blog.ataxya.net) à propos de ça. Vu que sur internet je trouve 
beaucoup plus de présentations commerciales que d'avis réels sur la 
solution, je me suis dit que j'allais demander à mon groupe d'expert 
préféré ce qu'il pense de cette techno. Mes questions sont donc : - 
Pourquoi passer au SDN ? - Il y a-t-il un réel intérêt de passer au 
SDN ? (Hormis l'aspect commercial) - En avez-vous déjà mis en place ? 
Comment ça s'est passé ? Avez-vous remarqué un réel changement dans la 
façon de faire vos réseaux ? (et du gain de temps ?) - Pensez vous que 
dans 5,10,20 ans, tous les réseaux seront du SDN ? Je suis à l'écoute 
de tous vos retours, ça me permettra de mieux comprendre le SDN et 
l'intérêt (s'il y en a un) !

(Je sens que je vais lancer un long thread plein de débats :D)
Merci d'avance !

Cordialement,




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

Re: [FRnOG] [MISC] Le Soleil a t-il un effet sur les réseaux

[Pierre Colombier via frnog]

J'avoue que ça, je n'y comprend rien.

je ne vois pas en quoi l'origine de temps apporte une information utile 
pour discriminer un symbole d'un autre.


Mais si il y a une explication pas top obscure quelque part, je veux 
bien un lien.



On 19/05/2021 09:32, Stéphane Rivière wrote:

Grand classique : la réception synchrone, qui permet de reconstruire la
forme d'onde statistiquement la plus probable, en fonction de l'origine
de temps du symbole à décoder.



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

Re: [FRnOG] [MISC] Le Soleil a t-il un effet sur les réseaux

[Pierre Colombier via frnog]

Tu veux dire qui traverse tout ça tranquile, mais qui interagit quand 
même suffisamment avec la fibre pour perturber ce qui passe dedans...


là, je ne vois pas..


+1 pour la pelleteuse :)


On 18/05/2021 18:15, Michel Py via frnog wrote:

. C'est donc quoi qui traverse l'atmosphère, la gaine, et 30 cm de terre ?



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

Re: [FRnOG] [MISC] Le Soleil a t-il un effet sur les réseaux

[Pierre Colombier via frnog]

Je ne vois pas par quel principe ça aurait la moindre incidence sur les 
fibres optiques


ni d'ailleurs sur la majorité des faisceaux hertziens (ceux à vue directe)

Je veux bien qu'il y ait des problèmes avec les réseaux electriques, et 
que ça impacte les télécom par effet domino.


mais pour expliquer des dysfonctionnement de 4G, je crois qu'on est dans 
la BOFH excuse.




On 14/05/2021 12:36, Wallace wrote:

Ça expliquerait pourquoi entre hier et aujourd'hui j'ai des
perturbations sur des vpn over 4G?

Parce que je galère à trouver une raison dans le dysfonctionnement de
liaisons qui marchaient très bien avant...

Merci pour la BOFH excuse :D même si ça ne résoud pas mon problème

Le 14/05/2021 à 11:04, Gilou a écrit :

Le 12/05/2021 à 18:24, Stephane Bortzmeyer a écrit :

Le Soleil est chaud bouillant en ce moment (le cycle 25 monte en
puissance ). Mais
est-ce que ça a réellement un impact opérationnel ? Avez-vous vu
quelque-chose entre 1200 et 1500 UTC ?

Hello,

Je suis tombé par hasard sur
https://www.franceinter.fr/oeuvres/meteorologie-de-l-espace
qui éclaire (haha) sur les vents solaires et les perturbations
potentielles, notamment une éruption dont j'ignorais tout, générée par
le cycle 22 : https://fr.wikipedia.org/wiki/%C3%89ruption_solaire_de_1989

Je ne pensais pas que les éruptions solaires étaient plus qu'une BOFH
excuse, c'est passionnant !

@+
Gilou


---
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] [BIZ] French Terminology - Wavelength

[Pierre Colombier via frnog]

"Wavelength" translates to "Longueur d'onde"


"Ondes" is definitively the right term for "waves" like radio waves.

"Vague" is for the sea waves.

in other contexts and especially in technical and scientific language, 
"Vague" would first be undertood as "unclear"/"fuzzy" unsless it 
visually refers to the curve or progagation of sea waves.







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

Re: [FRnOG] [MISC] 5G décentralisée sur la blockchain [troll?]

[Pierre Colombier via frnog]

"éco-conscient" ? rh ! joli!! succès garanti !



On 03/05/2021 12:33, Stéphane Rivière wrote:

Tu pourrais rajouter IA, devops, éco-conscient, et tant de bullshit...





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

Re: [FRnOG] [MISC] 5G décentralisée sur la blockchain [troll?]

[Pierre Colombier via frnog]

Non, je parle juste des projets où "y'en a dedans" sans que cette techno 
ait de rapport direct avec le sujet.



On 03/05/2021 01:14, neo futur wrote:

On Sun, May 2, 2021 at 6:53 PM Pierre Colombier via frnog
 wrote:

Est-ce que je suis le seul vieux con rétrograde à faire du classement
vertical catégorie "halacon" (ou "troll velu") dès que le mot blockchain
apparait quelque part ?

Si tu penses que tout ce qui est blockchain est nécessairement bête ou
inutile, je te conseille de te renseigner sur les applications
possibles . Pour te donner des idées de l'étendue des possibles,  je
te recommande le visionnage de
https://www.youtube.com/watch?v=XeqIfr1Oxwk




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

Re: [FRnOG] [TECH] recherche equivalent au mikrotik rb4011

[Pierre Colombier via frnog]

bah avec ton budget de 1.5k€ tu peut acheter près d'une dizaine de RB4011.

Donc je ne comprends pas quel est ton problème de spare ?

Le 02/05/2021 à 18:33, Benoit Chesneau a écrit :

J’ai été assez échaudé par le support de mikrotik en cas de panne dernièrement. 
Avoir du spare ne garantit aucune tranquillité vu qu’une réparation prend min 
2-3 semaines…

Je me demandais donc si il existe un equivalent au RB4011 [1] avec au moins une 
sortie SFP+ pour être connecté sur un switch (downlink) en 10G. Le up est max 
1Gbps. Le tout avec possiblement du support D+1 sans rentrer dans des budgets 
astronomiques < 1.5K € . Si vous avez des idées je suis preneur.

Benoît

Sent from ProtonMail for iOS
---
Liste de diffusion du FRnOG
http://www.frnog.org/



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

Re: [FRnOG] [MISC] 5G décentralisée sur la blockchain [troll?]

[Pierre Colombier via frnog]

Est-ce que je suis le seul vieux con rétrograde à faire du classement 
vertical catégorie "halacon" (ou "troll velu") dès que le mot blockchain 
apparait quelque part ?


J'attends avec impatience l'arrivée d'IP over blockchain.


Le 02/05/2021 à 17:54, Vincent Habchi a écrit :

Salut !


De ce que j'ai compris, la fréquence utilisée par le projet Helium
fait partie de la bande CRBS 3.5GHz que la FCC met à disposition pour
des usages personnels et commerciaux du citoyen lambda (general
public, cf : 
https://www.fcc.gov/wireless/bureau-divisions/mobility-division/citizens-band-radio-service-cbrs).
Partant de là, je me suis demandé si une législation équivalente
existait dans nos contrées (je suis en France Métro.), partant du
principe que si tel règlement existait, il serait établi au niveau de
l'Europe dans la logique "réguler des ondes ça se fait à minima à
l'échelle d'un continent".

Alors, pour commencer, il y a une organisation mondiale des télécoms, qui 
s’appelle UIT (Union Internationale des Télécommunications). En ce qui la 
concerne, le monde est divisé en 3 zones : zone 1 = Europe + Afrique + Partie 
de l'Asie ; Zone 2 = Amériques ; Zone 3 = Le reste. Dans chaque zone, il y a 
des bandes de fréquences réservées pour différentes « classes de services » : 
fixe, mobile, radioastronomie, radioamateurs, radiolocalisation, radiodiffusion 
… et les bandes dites « ISM » Industriel/Scientifique/Médical qui sont, en 
réalité, des bandes fourre-tout où les émissions peuvent normalement se faire 
sans licence. Exemple de telles bandes : 27 MHz (ancienne CB) / 432 MHz 
(télécommandes de voitures, portails…) / 2400 MHz (Wifi 1er génération, 
bluetooth, fours micro-ondes) / 5600 MHz (Wifi 2de génération) / etc. Il y en a 
des plus hautes.

En dehors de ces bandes internationales, rien n’empêche une ou plusieurs 
administrations d’ouvrir d’autres plages de fréquence à des utilisations 
libres, pourvu qu’elles ne gênent pas les utilisateurs normalement autorisés. 
On appelle ça du service secondaire (en fait, c’est même moins que du 
secondaire ici). Par exemple, les talkie-walkies grand-public opèrent 
maintenant vers 800 MHz je crois. En Europe, c’est la CEPT qui gère de telles 
allocations, de sorte que le matériel vendu en Allemagne fonctionne aussi en 
France ou en Italie, et lycée de Versailles. Estampillage CE.

Alors, pour en revenir à la 5G, déjà, il faudrait voir quelle largeur de bande 
exige une véritable application 5G. En plus de ça, tu n’aurais aucune garantie 
de non-brouillage par un autre dispositif totalement incompatible mais occupant 
la même fréquence (pense, par exemple, à un four à micro-ondes, ou un 
talkie-walkie analogique). Là-dessus, la puissance sur les bandes ISM est 
souvent sévèrement bridée (genre 500 mW maxi).

En France, de toute manière, tu n’as pas le droit de connecter un réseau radio 
au réseau de téléphonie sans posséder une licence. Tu pourrais sans doute 
essayer de faire de la 5G sur une bande ISM suffisamment large, mais il te 
faudrait des téléphones adaptés ! Les smartphones ne sont pas prévus pour 
recevoir les fréquences des bandes ISM.

Bref, ça me paraît assez utopique, pique et colégram.

Vincent


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



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

Re: [FRnOG] Re: [TECH] Une announce BGP inhabituelle (armée étatsunienne)

[Pierre Colombier via frnog]

D'après

https://fr.wikipedia.org/wiki/%C3%89chelles_longue_et_courte#Usage_britannique_ou_canadien

Le terme « /milliard/ » est maintenant obsolète en anglais britannique, 
et « /billion/ » ne veut rien dire d'autre que 10^9 dans tout ce qui a 
été publié depuis beaucoup d'années maintenant. Le gouvernement 
britannique et la BBC 
 
utilisent l'échelle courte exclusivement. Toute personne qui 
/délibérément/ utilise « /billion/ » pour vouloir dire 10^12 en anglais 
britannique est sûre d'être incomprise.



On 25/04/2021 07:35, 'Stephane Bortzmeyer' wrote:

On Sat, Apr 24, 2021 at 08:37:18PM +,
  Michel Py  wrote
  a message of 147 lines which said:


Attention aux faux-amis ici, en anglais un "billion" c'est 10^9,
alors qu'en français un "billion" c'est 10^12.

Non, en anglais, un "billion", c'est 10^12, c'est en états-unien que
ça vaut 10^9 :-)


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


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

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

[Pierre Colombier via frnog]

chacun vit avec son temps.

Je ne reprocherai pas a un jeune d'ignorer des technos un peu anciennes.

Mais j'ai beaucoup plus de mal avec ceux qui osent marquer "maitrise de 
[tech]" dans leur CV alors qu'ils ont généralement fait qu'éfleurer le 
sujet avec des outils "clé en main".


On se retrouve avec des gens qui "maitrisent C/C++ sur microcontrôleur " 
qui ne sont jamais sortis de l'arduino, n'ont pas idée de ce qu'est un 
makefile, hésitent entre le & ou le * pour les pointeurs et n'ont pas 
vraiment idée de ce que peut être un vecteur d'interruption



Le 19/04/2021 à 19:12, Oliver varenne a écrit :

aussi fait quelques cours avec un logiciel permettant de "dessiner" un circuit 
logique
Me rappel plus le nom. C'était rigolo

Mais c'était y'a quelques années déjà. J'ai tout oublié.





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

Re: [FRnOG] [TECH] Bitream -> Bras alternatives a JunCisco?

[Pierre Colombier via frnog]

J'emploie xl2tpd depuis des années sur des APU,

ça ronronne.




On 01/04/2021 15:30, Mathieu wrote:


Le 01/04/2021 à 12:03, Dominique Rousseau a écrit :

2 choses que font l2tpns que j'ai cité :)
( à prendre là https://code.ffdn.org/l2tpns/l2tpns ou paquet Debian
récent, celui sur sourceforge qui est mieux référence est obsolètes )

super, je vais tester ça, en plus il y a la 2.3.3 dans les backports debian, ça 
semble la dernière version :)

Mathieu



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



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

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

[Pierre Colombier via frnog]

Pas depuis 1999 ;)

On 16/03/2021 11:16, Richard MATOS wrote:

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 ?



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

Re: [FRnOG] [TECH]problème de flash avec ubiquity ES16-XG

[Pierre Colombier via frnog]

Je réponds à plusieurs questions à la fois

la puce est une flash SPI modèle MX66L51235F (64Mo)

elle a le plan suivant

0x-0x001c : "u-boot"
0x001d-0x001d : "env"
0x001e-0x001e : "shmoo"
0x001f-0x001f : "eeprom"
0x0020-0x01af : "image1"
0x01b0-0x033f : "image2"
0x0340-0x03ff : "cfg"

image1 et image2 sont du ssquashfs

seule la zone "cfg" et un bout de image2 semblent avoir des trous.

(grandes zones qui lisent tout le temps 0x00 alors qu'un bloc vide est 
sensé lire 0xFF)


le bloc "env" semble contenir les parametres de boot, la cmdline du 
kernel, le baudrate du port série, ce genre de choses...


le bloc "eeprom" contient entre autre l'adresse mac du switch, son 
serial number etc...


la zone cfg est un filesystem "jffs2"

je l'ai reformaté sans que ca change quoique ce soit.

J'ai également mis le firmware à jour, (2 fois) sur la nouvelle puce, ce 
qui est sensé avoir écrasé les zone image1 puis image2 et donc purgé 
d'éventuelles erreurs si il y en avait eu.


Toujours le même comportement et toujours après 15 minutes d'uptime, que 
la conf soit complexe ou triviale.


C'est pour ça que je commence à m'interroger sur la zone OTP qui est 
dans la flash.


Pour faire la copie, j'ai utilisé petit dongle usb made in china basé 
sur le CH341A avec le logiciel flashrom.


flashrom affiche un warning à propos de la zone OTP de cette puce qui 
est une page hors adressage standard et qu'il ne peut ni lire ni écrire.


je reçois un "vrai" programmateur la semaine prochaine qui est sensé 
pouvoir cloner cette partie aussi.



Au sujet du fait que ça ne vaille pas le coup pour un switch à 
500balles. On est bien d'accord. Mais par contre, pour une quinzaine de 
switch qui risquent de tous avoir la même maladie à plus ou moins court 
terme, j'avoue que ça m'arrangerait bien de leur offrir une seconde vie 
pour 20 minutes de transplantation chacun.



En tout cas je note bien l'idée de cloner un switch en état de marche.

Si j'ai aussi l'erreur A12 en faisant ça, c'est qu'il y a une protection 
anti-bidouille, et je vais lacher l'affaire mais j'avoue que je ne 
comprends pas l'intéret commercial de ce genre de pratiques pour le 
fabricant. Comme si ces mésaventures pouvaient m'inciter à remettre un 
euro dans le jukebox






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

[FRnOG] [TECH]problème de flash avec ubiquity ES16-XG

[Pierre Colombier via frnog]

Bonjour,

J'ai un petit souci avec des switches ubiquity ES16-XG.

Pour faire simple, il n'y a qu'une seule puce de flash dedans et si on a 
le malheur d'activer les log persistents, on fini par la bruler.


Passe encore si ça ne concernait qu'une cellule dédiée mais et pour 
achever le problème, les logs sont dans le même filesystem que la conf


G!


Usuellement, je devrais juste dire que le switch est mort est passer à 
autre chose...


Sauf que j'en ai quand même un beau petit paquet qui ont été soumis au 
même traitement et que j'ai peur d'avoir très bientôt une épidémie de 
flash corrompues.



Du coup, je décide de "tenter des trucs".

je dessoude la puce de flash (MX66L51235F) et je la recopie dans une neuve.

Yahoo, ça boot, je peux enregistrer la conf et ça la prends bien au 
reload. tout est nickel.


Petit excès d'enthousiasme qui termine sur une douche froide car au bout 
d'une 15 minutes d'uptime le switch clear (presque) toute sa running 
config et règle son hostname à "Error-A12".


Pas moyen d'avoir une info sur ce qui ne va pas auprès du support.

Pas moyen d'obtenir une image "failsafe" de ce qu'il devrait y avoir 
dans la flash.


scrogneugneu...

Alors, peut être que c'est pas seulement la flash et qu'il est vraiment 
mort ?


Juste pour voir, je ressoude la vieille puce, et ce qui est surprenant, 
c'est qu'avec celle la, il n'y a évidemment plus possibilité 
d'enregistrer la conf dans la zone cramée mais par contre ça ne fait pas 
l'erreur A12...


Hummm c'est qu'en fait, c'est pas un clone parfait que j'ai fait...

This chip may contain one-time programmable memory. flashrom cannot read
and may never be able to write it, hence it may not be able to completely
clone the contents of this chip (see man page for details).


Je suis peut-être parano mais est-ce qu'au lieu d'être simplement mal 
conçu ça ne serait pas au contraire bien conçu pour être pénible ?


Juste pour le plaisir de l'exercice, est-ce qu'il y en a sur la liste 
qui se sont déjà ammusés à ce genre de sport et avec quel succès ?


(et bien entendu, auraient ils des conseils à donner ?)










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

Re: [FRnOG] [TECH] Réparation onduleur APC, il est où le GREEN-IT ?

[Pierre Colombier via frnog]

Un réparateur "pro" te coutera plus cher que l'onduleur.

Par contre si tu veux le récupérer pour du perso et que tu ne regarde 
pas trop ton temps



En première approche, change toutes les capa electrochimiques.

Oui, toutes. Certaines seront inévitablement moins tabassées que 
d'autres mais elles ont le même âge et tu gagnera un temps fou vs 
analyser une par une.


Si ça déconne toujours.

Regarde les resistances de gros calibe. Certaines peuvent se couper ou 
changer de valeur en chauffant.


En général ça se voit quand elles ont souffert (ou le PCB autour qui a 
bruni).


Si ça ne va toujours pas, c'est inquiétant.

Regarde les relais. qui ont peut-être des contacts usés.

et enfin les gros composants de puissance mosfet/diodes mais c'est 
probablement pas ça car sinon, les fusibles auraient probablement pétés.


Si ça ne va toujours pas, considère que c'est mort.

Les pannes compliquées requièrent trop de temps d'analyse vs le prix de 
la machine.





On 28/01/2020 17:58, Stéphane Rivière wrote:

Est-ce que quelqu'un a un contact qui saurait réparer ça ?

ECUS Ondulique, demander Jean-Christophe Romé - 06 64 63 80 95 - j...@ecus.fr

Ils faisaient dans ces classiques là, je ne sais pas s'ils font
toujours. Toujours en contact avec eux depuis... 1994 - argh :()

J'utilise plutôt leurs gammes propres d'onduleurs. Mais j'ai pris en son
temps pas mal d'APC, puis de l'EATON / POWERWARE chez eux.

Avec aussi des gammes de baies à des prix très concurrentiels (entre
autres). Et du mini DC en baie climatisée. Enfin faut voir leur site.




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

[FRnOG] [TECH] DoH et DHCP

[Pierre Colombier]

Bonjour,

Il me semble étonnant que les grands navigateurs veuillent déployer DoH 
sans qu'il existe préalablement un moyen centralisé de spécifier l'URL 
du serveur DoH en question.


J'ai trouvé ça 
https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet


mais je trouve que ça sens le bricolage improvisé.


Sinon, ceci me semble plus sérieux

https://tools.ietf.org/html/draft-peterson-doh-dhcp-01

qu'en pensez vous ?




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

[FRnOG] [TECH] Supprimer IPV4 RFC1918 dans un LAN ?

[Pierre Colombier]

Bonjour,

Suite à la mise en place de IPv6 dans un LAN, je n'ai plus besoin d'IPv4 
dans ce réseau.


De ce fait, il m'est pénible de maintenir la dual-stack avec des IPv4 
RFC1918 qui ne servent qu'a accéder à l'internet v4 via un NAT en bordure.



La question est sans doute ancienne mais je voudrais savoir si il existe 
un moyen de supprimer la stack IPv4 dans le lan tout en gardant un NAT 6 
vers 4 pour accéder au "vieux" net v4.


Le truc qui semble le plus intuitif est le NAT-PT où on mappe les 32 
bits IPv4 dans un prévixe IPv6 mais le problème plus difficile est alors 
de maper aussi les enregistrements DNS A dans des  correspondants.


Avec tous les efforts de sécurisation de DNS en ce moment, ce genre de 
manipe risque de poser plein d'autres problèmes.


Aparemment le NAT-PT est déconseillé par l'IETF pour cette raison là.

Sauf que si c'est déconseillé, je n'ai pas trouvé l'alternative recommandée.

Je ne suis vraisemblablement pas le premier à me pencher sur ce 
problème, j'aimerais savoir si certains d'entre vous ont tenté ce genre 
de choses et si oui avec quels succès difficultés ou échecs.


Merci de vos réponses / suggestions


Pierre



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

Re: [FRnOG] [TECH] TR-069 - Mikrotik

[Pierre Colombier]

Quelqu'un a trouvé une méthode fiable pour faire marcher la netinstall 
mikrotik sans chopper de tendinite ?





On 24/10/2019 13:55, Timothé Perez wrote:

Plop,

Attention, le client TR-69 Mikrotik ne supporte pas l'IPv6 pour
communiquer avec l'ACS (peut être qu'en ROS 7 cela sera le cas).

--
Timothé Perez

Le jeu. 24 oct. 2019 à 11:48, David Ponzone  a écrit :




Le 24 oct. 2019 à 11:10, Kevin Thiou  a écrit :

j'ai trouvé ca :

https://mum.mikrotik.com/presentations/EU19/presentation_6365_1552304020.pdf 



I stand corrected.
Y a un mec qui partage, et pas qu’un peu en plus :)
C’est tentant parce que l’upload d’une conf dans un MK, c’est quand même bien 
pourri.



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


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



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

Re: [FRnOG] [TECH] Switch Ubnt et SNMP

[Pierre Colombier]

On 23/10/2019 23:23, alarig wrote:

Le 23/10/2019 à 19:57, Pierre Colombier a écrit :

Fantastique !

Je pensais justement à mettre à jour en espérant qu'il y ait un
support des compteurs 64 bits sur les ES16-XG.

L'argument DOS ne me parait pas pertinent. C'est à l'uager de savoir
  limiter son requêtage.

En plus, vu les CPU qu'il y a dans les switches maintenant, ça
devrait leur toucher un coeur sans faire bouger l'autre... ;)

Des trucs comme LibreNMS ou Observium ça peut être un peu bourrin parfois.


bah c'est comme tout, ça se règle ;)


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

Re: [FRnOG] [TECH] Switch Ubnt et SNMP

[Pierre Colombier]

Fantastique !

Je pensais justement à mettre à jour en espérant qu'il y ait un support 
des compteurs 64 bits sur les ES16-XG.


L'argument DOS ne me parait pas pertinent. C'est à l'uager de savoir 
limiter son requêtage.


En plus, vu les CPU qu'il y a dans les switches maintenant, ça devrait 
leur toucher un coeur sans faire bouger l'autre... ;)




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

Re: [FRnOG] [BIZ] Contôleur Aruba 7024 pas chère

[Pierre Colombier]

euh ? le POE existe physiquement mais nécessite un licence ? sans 
déconner ?


bon bah merci de m'avoir aidé à me faire un avis sur Aruba.

J'avoue de de loin, ça avait l'air bien .



Le 22/10/2019 à 20:17, ja...@free.fr a écrit :



Bonjour,


J'ai acheté pour une bouchée de pain un contrôleur Aruba 7024 neuf, sur un site 
de discount douteux Français.



Vu le tarif aberrant (35€), j'étais obligé de le prendre, juste pour voir :-) . 
Et éventuellement en faire le switch PoE de ma maison.



Et donc là j'ai bien vu, comme je m'en doutais, il y a un truc : il n'a aucune 
de licence.





Donc en l'état c'est un Switch 24 ports Gigabit. Et même pas PoE vu qu'il y a 
une licence pour ça...





Si ça intéresse quelqu'un, je le laisse pour le prix d'achat + port.


Il est neuf, c'est moi qui ai déchiré l'étiquette du sac anti-statique. J'ai 
vérifié sur le site HPE, il est garanti jusqu'au 20 fév 2020.




Produit : Aruba 7024 (RW) 32 AP Branch Cntlr
Numéro de produit : JW682A



Julien





PS: Si quelqu'un sait si j'ai une chance de retrouver les licences associées , 
je suis intéressé.


PS2 : Si quelqu'un sait comment ça se passe l'achat de licences, je suis 
intéressé.


PS3 : Je tente avec le vendeur, mais j'avoue que j'ai très peu d'espoir de ce 
côté.

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



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

Re: [FRnOG] [MISC] La taxe sur IPv4

[Pierre Colombier]

On 11/10/2019 08:45, Philippe Beauchet wrote:


Et puis de toute façon, théoriquement, on est censé faire du NAT 
partout. Alors 4 ou 6 en sortie...du moment que mon parc est en 4 ;)




Oui alors c'est pas forcément très simple.


Autant un nat permettant au V6only d'acceder au vieux V4... pourquoi pas.

Autant nater les paquets V4 vers du V6, je ne vois pas bien comment ça 
va faire.


si tu n'as que du , elle fait comment ta machine v4 pour savoir à 
qui envoyer le paquet ?



Alors a priori, je trouve que ça va être compliqué de nater un parc V4 
derrière du V6


en tout cas ça me semble nettement plus compliqué que de passer en dual 
stack.



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

[FRnOG] [TECH] VPN ou PPP sur MTU variable

[Pierre Colombier]

Je rebondis sur le sujet "VPN en 2019" pour soumettre un problème que 
j'ai régulièrement.


Comme maintes fois évoqué un VPN qui vise à la mobilité doit presque 
obligatoirement être en mode client/serveur et traverser le NAT.


Seulement voilà, quand on fait un VPN à travers de la 4G/3G. il peut 
arriver que la MTU varie drastiquement dans le temps


J'ai vu des liens tomber en dessous de 700 dans des situations de 
roaming et/ou de dépassement de forfait.


Or, le protocole du VPN fait généralement une détection au début pour 
calculer la MTU du lien et crée éventuellement des règles de réécriture 
du MSS tcp, mais il ne détecte pas quand ça change. Du coup, il faut 
attendre le timeout, que le VPN tombe et que ça renégocie.


(et au pire, tout déconne mais ça déconnecte pas car les keepalive 
passent quand même)



Du coup, je me demandais si il y avait des VPN courant qui redétectent 
régulièrement la pMTU ou qui au moins tiennent compte de RFC1191 et 
RFC8201 ?





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

Re: [FRnOG] [TECH] Fin du RTC, onduleur obligatoire ?

[Pierre Colombier]

il est écrit dans l'article que "les lignes existantes cesseront de 
fonctionner au plus tard fin 2023"


Ah oui ??? Et quand on habite au fin fond de la camberousse avec du 
re-dsl tout pourris qui passe plus de temps en resynchro que up ? on 
fait comment pour téléphonner ? on ressort la vielle VHF du grenier ?



On 17/09/2019 15:32, Richard Klein wrote:

Bonjour,

Je relance le sujet sur la fin du RTC et les solutions de remplacement Made
in Bordeaux :
https://www.lembarque.com/la-fin-du-reseau-telephonique-commute-(rtc)-profite-au-bordelais-edevice_009042


https://www.edevice.com/products/wirex

Je ne suis pas de Edevice :-)

Richard

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



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

Re: [FRnOG] Re: [tech]interrogations sur doh

[Pierre Colombier]

Je faisais référence au résolveur interne de la machine.

le mécanisme qui est appelé avec les fonction gethostbyname() par exemple.

Je suis d'accord avec toi sur le fait que tu peux ne pas faire confiance 
à ton FAI.


Par contre, si tu ne fais pas confiance à ta propre machine, là, il faut 
juste cesser de t'en servir.


Pour ce qui est de « si je me connecte en TLS au serveur de la Maison 
Blanche, ça ne me garantit pas que Trump dira la vérité » On peut 
retourner l'argument : je ne vois pas bien en quoi le resolveur de 
google ou n'importe quel gros fournisseur serait tellement plus 
respectable que celui de mon FAI.



Dernier petit point : avec toute cette sécurité, comment on va faire 
pour dépanner vite fait quand le serveur DOH en top list du browser sera 
en rade ?


(ce qui arrivera forcément un jour où l'autre)





On 17/09/2019 16:18, Stephane Bortzmeyer wrote:



Sinon, ce que je trouve dérangeant c'est pas le protocole lui même, c'est
que les navigateurs n'utilisent plus le résolveur local. (lequel pourrait
très bien faire du DOH).

Ben, c'est un peu le but. Si on a envie d'utiliser DoH ou DoT, c'est
qu'on ne fait pas confiance au réseau d'accès. Faire du DoH avec un
résolveur local en lequel on n'a pas confiance, c'est oublier la règle
numéro un de TLS « si je me connecte en TLS au serveur de la Maison
Blanche, ça ne me garantit pas que Trump dira la vérité ».


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



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

Re: [FRnOG] [tech]interrogations sur doh

[Pierre Colombier]

On 17/09/2019 11:19, Julien Escario wrote:

Le 17/09/2019 à 11:09, Pierre Colombier a écrit :

Bonjour,

J'ai regardé la vidéo de Stéphane sur DOH. (mais j'ai pas lu la RFC)

Le premier truc qui me viens à l'esprit c'est un problème de poule et
d'oeuf.

Le résolveur DOH est une URL => comment résout-on cette url ?

il y a une liste d'IP résolveurs DOH ? un peu comme il y a une liste de
DNS root ?

si oui ou est-elle ? et peut-on la modifier facilement ?

Rhalala, fallait venir vendredi dernier, je l'ai posée celle là ;-)

En gros, pour résoudre l'URL, on utilise ... DNS ! (aka du bon vieux
UDP/53).


J'ai eu un décrochement de machoire un instent...

mais non, tout va bien. Le cas ou on aurait traffiqué cette première 
requete est géré par le certificat http.





Il va falloir
intégrer que l'utilisateur 'lambda' passe par DoH même si ce n'est pas
ton cas.



En fait, je m'en fiche pas mal de comment les usagers lambda font leur 
résolutions DNS du moment qu'ils ne viennent pas m'emmerder avec. Mes 
routeurs ont un proxy que je pousse par DHCP pour rendre service mais en 
fait ils font bien comme il veulent. C'est pas mon problème... Il y en a 
un certain nombre qui préfèrent mettre 8.8.8.8 non pas à cause d'un 
légitime problème de confiance mais parce qu'ils ont lu dans une feuille 
de chou que c'était mieux.


Par contre, j'entends que mon navigateur m'obéisse. Et à chaque fois 
qu'il va quand même taper le vieux serveur alors que ping tappe le bon, 
je fais une crise d'urticaire.








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

Re: [FRnOG] [tech]interrogations sur doh

[Pierre Colombier]

On 17/09/2019 11:35, Étienne wrote:


Je n'aime pas non plus que mon navigateur utilise sa propre suite de
certificats SSL root alors que l'OS a sa propre liste.


bien vu.

C'est effectivement du même ordre.




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

[FRnOG] [tech]interrogations sur doh

[Pierre Colombier]

Bonjour,

J'ai regardé la vidéo de Stéphane sur DOH. (mais j'ai pas lu la RFC)

Le premier truc qui me viens à l'esprit c'est un problème de poule et 
d'oeuf.


Le résolveur DOH est une URL => comment résout-on cette url ?

il y a une liste d'IP résolveurs DOH ? un peu comme il y a une liste de 
DNS root ?


si oui ou est-elle ? et peut-on la modifier facilement ?


Sinon, ce que je trouve dérangeant c'est pas le protocole lui même, 
c'est que les navigateurs n'utilisent plus le résolveur local. (lequel 
pourrait très bien faire du DOH).


Déjà que le fait que les navigateur emploient leur propre cache est un 
problème lourd pour le débogage depuis des années. ça promet d'empirer 
considérablement.



Voila, c'est juste des interrogations personnelles sur le sujet. 
N'hésitez pas à placer vos 2 cents ;)











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

Re: [FRnOG] [TECH] Optiques compatibles Stormshield

[Pierre Colombier]

Bonjour,

J'ai déjà crisé sur cette liste à propos de de ces limitations idiotes 
en 2016 dans un sujet intitulé "[TECH] SFP encoding" et j'ai finalement 
publié ce petit projet.


https://hackaday.io/project/21725-pihat-sfp-encoder


J'ai entendu qu'il y aurait des cartes réseau qui exposent le bus I2C du 
sfp et permettent donc la reprogrammation directement. mais je ne me 
rapelle plus de marque ou du modèle.



A la limite, si tu as déjà des optiques estampillées de la bonne marque, 
tu peux t'ammuser à recopier leur code dans une optique générique


En ce qui me concerne c'était pas un problème de marque mais de 
catégorie de SFP.


Le switch prenait les LX mais pas les bidir alors qu'en fait, c'est les 
mêmes signaux.


J'ai donc juste déclaré que mes bidir1310/1550 étaient des LX 1310nm et 
pouf magie !



J'ai aussi eu à peu près la même chose avec du 10G cuivre "direct 
attached" qui est subitement devenu de la fibre multimode.



Cela dit, du temps a passé et aujourd'hui je ne rencontre plus jamais de 
problèmes de ce genre.


Des fois on a pas vraiment le choix mais par principe, j'aurais tendance 
à bannir toute marque s'ammusant encore à pratiquer ce type de racket 
sur les optiques.



My 2 cents...






On 30/08/2019 08:28, Charles Koprowski wrote:

Le ven. 30 août 2019 à 01:53, Michel Py 
a écrit :


Ah la vache $600 pièce pour du NA-TRANS-DUALSFP-SR, on comprends que tu
sois tenté.


Oui ça me ferait mal de payer ce prix la juste pour avoir un autocollant
Stormshield dessus…



Est-ce que tu as demandé à FS s'ils pouvaient te coder les optiques pour
Stormshield ?

Essaies leur optique "générique" aussi, pas seulement l'Intel à 16€ pièce
çà va pas te ruiner.


FS me recommande les codées Intel ou les génériques en effet.

D'autres retours en privé m'indiquent que cela fonctionne avec des DAC HPE,
des optiques FS (codées Juniper), des pureoptics (codées Stormshield).

Plutôt rassurant donc.



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

Re: [FRnOG] [TECH] linux route cache

[Pierre Colombier]

Ok pour la disparition du route cache.

Par contre, l'impossibilité d'avoir la liste des exceptions, c'est quand 
même problématique.




On 22/08/2019 13:31, Vincent Bernat wrote:

  ❦ 22 août 2019 12:21 +02, Pierre Colombier :


Il n'y a plus de cache depuis Linux 3.6. C'est remplacé par des
exceptions qui sont attachées à chaque entrée. À ma connaissance, il n'y
a pas moyen de dumper l'intégralité de ses infos.



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

[FRnOG] [TECH] linux route cache

[Pierre Colombier]

Bonjour,

Je voudrais afficher le cache de routes pour savoir celles qui sont 
issues de icmp_redirect et également celles pour lesquelles PMTUd a 
renseigné une valeur spéciale.


et le comportement ne ressemble pas aux exemples que j'ai pu trouver sur 
le net.


exemple:

pierre@zebulon: ~ $ ip route get to 172.28.1.200
172.28.1.200 via 192.168.68.254 dev enp4s0 src 192.168.68.20 uid 1000
    cache

Je génère exprès un paquet trop gros.

pierre@zebulon: ~ $ ping -M do -s 1400  172.28.1.200
PING 172.28.1.200 (172.28.1.200) 1400(1428) bytes of data.
From 192.168.68.254 icmp_seq=1 Frag needed and DF set (mtu = 1400)
ping: local error: Message too long, mtu=1400

pierre@zebulon: ~ $ ip route get to 172.28.1.200
172.28.1.200 via 192.168.68.254 dev enp4s0 src 192.168.68.20 uid 1000
    cache expires 595sec mtu 1400


jusque la tout se comporte comme attendu.

Par contre,

pierre@zebulon: ~ $ ip route show cache

ne retourne rien. (et ne se plaint pas non plus)

J'aurais aimé avoir toute la liste plutôt que de spécifier une cible.

Est-ce que je me trompe de cache ?

est-ce ça a changé récemment ?


Merci d'avance pour vos lumières ;)






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

Re: [FRnOG] [TECH] Cloudflare Magic Transit

[Pierre Colombier]

Euh, j'ai du rater un bout du concept ?

si cloudflare est l'unique transitaire, on interconnecte comment avec ?

Il faut un L2 dédié ?

ou bien c'est un genre de VPN ?

ou bien encore c'est juste un genre de proxy filtrant ?


On 18/08/2019 17:51, Jonathan Leroy - Inikup wrote:

Salut à tous,

En début de semaine, Cloudflare a lancé Magic Transit :
https://www.cloudflare.com/magic-transit/
Deux billets sur le blog qui détaillent le fonctionnement technique :
  - https://blog.cloudflare.com/magic-transit-network-functions/
  - https://blog.cloudflare.com/magic-transit/

Il s'agît si j'ai tout compris d'une offre de transit IP "exclusive",
dans le sens où tout le trafic passe par Cloudflare, qui est votre
unique transitaire et se charge de le nettoyer en utilisant sa
technologie magique. Puis tunnel GRE entre Cloudflare et le routeur
client. Pas de tarif public évidemment.

Curieux de connaitre votre avis sur le produit.




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

Re: [FRnOG] [MISC] Stabilité RouterOS Mikrotik

[Pierre Colombier]

Hello. (Je sujet déviant un peu j'ai modifié le titre du mail)

En fait, j'ai sauté des versions 6.44

j'ai du passer de 6.43.16 qui était hyper stable sur plusieurs gros 
routeurs à la version 6.45.1 puis 6.45.3


dès le départ la 6.45.1 a semblé a voir du mal à gérer plusieurs full 
view bgp


 - plusieurs bgp hold timer par jour, soit chez moi soit chez le peer

 - des crash/reboot par watchdog.

 - Autre WTF, appatition de temps à autre de paquets bizares avec 
macaddr src et dst aparemment random et qui déclanchaient la sécu du 
switch de mon peer.


Apparemment mes traces sont un peu trop ténues pour que le le support 
mikrotik y prenne au sérieux.


Visiblement la 6.45.3 ne corrige pas ce problème et par ailleurs, comme 
c'est de la prod, j'ai rapidement arrété les frais et downgrade en 
6.43.16 => tout roule à nouveau.




Sur un autre routeur je suis en 6.45.3 mais sans bgp.

là, tout semblait bien marcher mais apparition de pertes de paquets 
occasionnelle au bout d'une trentaine de jours d'uptime.


sous réserve de tests complémentaires il semble que certaine routes 
deviennent inactives car nexthop unreachable (alors que si)


et j'ai repéré quelques émissions de BPDU anormales (pas la bonne 
macaddr + priorité de bridge = 0x+flag TC) déclanchant des 
changement de topologie RSTP sur d'autres routeurs.


Un simple reboot a réglé le problème mais c'est très dérangeant. ce 
genre de paquet WTF, ça sent un peu la corruption de mémoire dans les 
couches basses...


-> j'ai pas fait de downgrade sur celui là mais c'est sous surveillance.


Pour ma part je n'ai jamais eu à me plaindre de la 6.43.16. sur aucun 
matériel mikrotik (que ce soit CCR, CRS ou RB) Je pense passer toutes 
les upgrades suivantes une par une et attendre à chaque fois au moins 15 
jours pour détecter à partir de laquelle ça foire. A ce moment là de 
recontacterai le support mikrotik pour leur demander ce qui a changé 
entre ces deux versions.


Si d'autres membres de la liste ont des comportements étranges 
(similaires ou non) suite à des upgrades de rOS, je suis preneur de 
toute info ;)






On 17/08/2019 18:53, David Ponzone wrote:

T’as essayé la 45.3 ?
Il me semble aussi avoir eu un truc bizarre mais plus en .3

David Ponzone




Le 17 août 2019 à 17:28, pierre colombier  a écrit :

J'ai quand meme de sérieux doutes depuis la version 6.45. il est possible que 
j'ai des problèmes qui viennent d'ailleurs mais j'ai quand meme quelques wtf 
depuis cette mise à jour.
Je n'ai pas encore assez de diags fermes la dessus mais j'aimerais savoir si 
d'autres ont noté une dégradation de la stabilité de rOS depuis juin dernier.



Le 13 août 2019 08:54:02 GMT+02:00, David Ponzone  a 
écrit :

Oui, hyper-stable comme leurs routeurs.


David Ponzone




Le 13 août 2019 à 08:46, Olivier Lange  a écrit :

Salut,

On en a une petite centaine en prod, plus ou moins chargée, dont notre cœur
de réseau interne. Sur du vmware et du proxmox. Zéro soucis. Prévois 1go
minimum et 2-4 vcpu pour être tranquille.

Olivier


Le mar. 13 août 2019 à 08:36, Sébastien Lesimple <
sebastien.lesim...@iguanetel.fr> a écrit :


Bonjour tous!

En cette quinzaine d'aout ou tout est à l'arret, je me demandais si
quelques uns d'entre vous avaient déjà testé du RouterOS (ou autre
d'ailleurs), sur de la VM?
J'imagine bien que le IaaS provider ou l'orchestrateur utilisé à un
impact mais l'idée c'est de voir ce que l'on peu faire avec.

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

--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

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



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

Re: [FRnOG] [MISC] RouterOS Mikrotik sur VM - Qq'un à tésté?

[pierre colombier]

J'ai quand meme de sérieux doutes depuis la version 6.45. il est possible que 
j'ai des problèmes qui viennent d'ailleurs mais j'ai quand meme quelques wtf 
depuis cette mise à jour. 
Je n'ai pas encore assez de diags fermes la dessus mais j'aimerais savoir si 
d'autres ont noté une dégradation de la stabilité de rOS depuis juin dernier.



Le 13 août 2019 08:54:02 GMT+02:00, David Ponzone  a 
écrit :
>Oui, hyper-stable comme leurs routeurs.
>
>
>David Ponzone
>
>
>
>> Le 13 août 2019 à 08:46, Olivier Lange  a écrit :
>> 
>> Salut,
>> 
>> On en a une petite centaine en prod, plus ou moins chargée, dont
>notre cœur
>> de réseau interne. Sur du vmware et du proxmox. Zéro soucis. Prévois
>1go
>> minimum et 2-4 vcpu pour être tranquille.
>> 
>> Olivier
>> 
>> 
>> Le mar. 13 août 2019 à 08:36, Sébastien Lesimple <
>> sebastien.lesim...@iguanetel.fr> a écrit :
>> 
>>> Bonjour tous!
>>> 
>>> En cette quinzaine d'aout ou tout est à l'arret, je me demandais si
>>> quelques uns d'entre vous avaient déjà testé du RouterOS (ou autre
>>> d'ailleurs), sur de la VM?
>>> J'imagine bien que le IaaS provider ou l'orchestrateur utilisé à un
>>> impact mais l'idée c'est de voir ce que l'on peu faire avec.
>>> 
>>> Seb.
>>> 
>>> ---
>>> 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/

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Meraki / Mikrotik soucis BPDU et flood des ports

[pierre colombier]

Si ce n'est pas déjà fait, je te conseille de fixer l'adresse mac de tous les 
bridges mikrotik ca evite les changements de topologie à chaque fois qu'elle 
change (par defaut, la mac la plus basse de toutes les interfaces up du bridge 
et ca peut donc changer sur un flap.)

Le 15 août 2019 11:27:28 GMT+02:00, David Ponzone  a 
écrit :
>
>Pas facile à diagnostiquer comme ça, mais sur 400 AP, t’es sûr que t’as
>pas un rigolo quelque part qui t’a fait une boucle avec un Port LAN
>libre de l’AP, en le branchant sur prise murale dispo à cet endroit, se
>pensant plus malin que les autres ? :)
>
>
>> Le 12 août 2019 à 23:24, Jérôme Quintard  a
>écrit :
>> 
>> Salut à tous,
>> 
>> J'ai une grosse contrainte de spanning tree entre un réseau Meraki et
>un ensemble d'AP Mikrotik configurés en CPE bridgé (donc se connectant
>à un AP meraki pour fournir du réseau à un unique périphérique
>filaire).
>> 
>> Ce mode de fonctionnement génère de gros soucis de convergence qui
>viennent mettre à plat le réseau (il faut dire qu'il y'a près de 400 AP
>Mikrotik). Côté log, on reçoit sur les switchs des masses d'évènements
>"STP BPDU sender conflict".
>> 
>> Meraki n'ayant pas de fonction BPDU filter, on a donc tenté de
>désactiver STP/RSTP sur l'interface bridge des AP Mikrotik pour couper
>court à tout soucis (bien que la priorité soit à 32768 par défaut).
>> 
>> Malgré ça le problème persiste, les AP réagissent aux annonces :
>> 
>> 
>> Port 22 received BPDU from 74:4D:28:A1:B5:B0, 1; expected
>74:4D:28:A3:B1:AB, 1
>> Port 22 received BPDU from 74:4D:28:A3:B1:AB, 1; expected
>74:4D:28:A1:B5:B0, 1
>> 
>> 
>> Quelqu'un a t'il ce type de soucis et une idée pour contourner la
>difficulté ? Les deux périphériques sont compatibles RSTP, je pense
>donc que ce n'est pas un soucis de protocole mais une conséquence de
>l'utilisation en CPE.
>> 
>
>
>---
>Liste de diffusion du FRnOG
>http://www.frnog.org/

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] l'abus de speedtest nuit à la senté de l'admin.

[Pierre Colombier]

Bien vu !! C'est en effet le cas !

Hé mais si ça se généralise ça sera bientôt les serveurs de speed-test 
qui vont demander grâce !


ça télécharge quand même presque 500Mo par test ! Plus gros qu'une iso 
d'installation linux. Quand je réalise qu'il est possible de faire ça 
régulièrement juste pour le plaisir de tracer un graphe, j'ai la 
sensation de prendre un coup de vieux !


Je me rends compte que j'ai sur-réagi en cherchant à réguler cette 
ânerie. Mais après tout, ça passe. Et le client peut se faire reluire en 
regardant son graphe.


Je ne vais rien brider, je vais juste demander au client si il veut bien 
espacer davantage ses tests.





Le 25/07/2019 à 02:48, Emmanuel Veyre a écrit :

Bonjour Pierre,

Ton client n'utiliserait-il pas une Unifi Security Gateway par hasard 
?? 


image.png



Le mer. 24 juil. 2019 à 15:51, Radu-Adrian Feurdean 
<mailto:fr...@radu-adrian.feurdean.net>> a écrit :




On Wed, Jul 24, 2019, at 00:24, Pierre Colombier wrote:

> Ensuite il se trouve qu'en théorie, je ne vends pas plus de 100M
mais
> qu'en pratique je ne bride pas et même si ce n'est pas dans le
contrat,
> je le dis et c'est un argument. => là c'est abuser de ma
gentillesse
> donc ça me gonfle => couic !

Donc tu le bride tout court. peut-etre pas a 100M pour eviter les
problemes, mais a 150, 200 ou 300 ca devra passer. Ca impacte
d'autres usages "legitimes" du meme lien ? Il y a une solution
(commerciale).


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



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

Re: [FRnOG] [TECH] l'abus de speedtest nuit à la senté de l'admin.

[Pierre Colombier]

C'est une bonne remarque et dans le principe je suis d'accord avec toi. 
mais dans le principe seulement.


Mon problème principal c'est essentiellement que "c'est moche" et "C'est 
du gaspillage" Si il employait 600M pour faire des backups, ça me ferait 
chier aussi mais ça serait un usage utile et donc quelque part légitime.


Ca n'est techniquement pas un problème MAIS si tous mes clients faisait 
ça, oui, ça serait vraiment un problème. surtout si ça arrivait du jour 
au lendemain.


Ensuite il se trouve qu'en théorie, je ne vends pas plus de 100M mais 
qu'en pratique je ne bride pas et même si ce n'est pas dans le contrat, 
je le dis et c'est un argument. => là c'est abuser de ma gentillesse 
donc ça me gonfle => couic !



On 23/07/2019 22:05, Hugues Voiturier wrote:

Y’a un truc qui me dérange pas mal, en quoi utiliser son lien pour faire des 
speedtests à longueur de journée serait un usage incorrect d’une FTTO ?

On est opérateur avec un devoir de neutralité sur ce qu’on transporte ou on est 
vendeur de trucs que les clients ne doivent surtout pas utiliser ?

Si 600Mbit/s symétriques arrivent à te poser un gros problème sur ton réseau ou 
sur la rentabilité de celui ci, c’est problématique quand même non ?

Sent from my iPhone





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

Re: [FRnOG] [TECH] l'abus de speedtest nuit à la senté de l'admin.

[Pierre Colombier]

Merveilleux :D


On 23/07/2019 21:51, Sebastien WILLEMIJNS wrote:

https://www.speedtestserver.com/

mais y'a mieux...  https://c.speedtest.net/speedtest-servers-static.php




On Tue, Jul 23, 2019, at 21:47, Romain wrote:

Y’a pas la liste des IP avec un (de mémoire) speedtest-cli -list ? (J’ai
plus l’option précise en tête).

Le mar. 23 juil. 2019 à 21:20, Pierre Colombier  a
écrit :


Bonjour la liste,

Je sais qu'on est pas trolldi mais ça presse un peu.



J'aurais besoin d'une liste des IP de serveurs de speedtest.net / ookla
/ nperf et autres exploseurs de commit.

ou d'une méthode pour la récupérer ou pour savoir si une ip particulière
en fait partie.


Disons que j'ai rien contre les tests, surtout quand il affichent des
resultats proches du gigabit.

Mais, il se trouve que j'ai un client qui semble souffrir de troubles
obsessionnels compulsifs graves.

Pour le moment, ce cas isolé ne fait pas grand choses de plus que de
pourrir mes graphes.

Mais, ça va vite poser problème si il s'avère que c'est contagieux.

Bref, Il faut que je lui fasse une ordonance.

J'ai pas envie de brider et que ça produise de mauvaises stats.

J'ai en tête un truc fin et subtil du genre

"Au delà de X Go / 24h échangés avec des serveurs de la liste (X à caler
pour equiv environ 20 tests ), tarpit toute la liste pour 48H"
















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


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



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



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

Re: [FRnOG] [TECH] l'abus de speedtest nuit à la senté de l'admin.

[Pierre Colombier]

il a mis un script qui tourne jour et nuit depuis vendredi.

(no-life mais pas complètement dingue)


J'avais mis un lien vers un graph rrd dans ma réponse à David mais ça a 
du être modéré. (ou c'est en attente)



On 23/07/2019 21:46, Michel Py wrote:

Pierre Colombier a écrit :
Mais, il se trouve que j'ai un client qui semble souffrir de
troubles obsessionnels compulsifs graves.

Il passe ses journées à faire du speedtest ? ou il a mis un script qui tourne 
toutes les 2 minutes ?

Michel.





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

Re: [FRnOG] [TECH] l'abus de speedtest nuit à la senté de l'admin.

[Pierre Colombier]

C'est de la FTTO.

Et quand je parle de troubles obscessionnels, c'est carrément du script 
qui tourne jour et nuit depuis vendredi dernier...


https://pasteboard.co/IplRPYr.png



On 23/07/2019 21:28, David Ponzone wrote:


C’est une client FTTO ?
Dans tous les cas, ces gens sont des no-life.
Soit t’es client FTTO, et si tu passes ton temps à faire des Speedtest, c’est 
flippant.
Soit t’es client FTTH, et là tu rejoins la cohorte d’abrutis qui mettent leur 
speedtest en signature sur lafibre.info


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



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