Re: [FRnOG] [MISC] Config ASR1001X

[Jérôme Berthier via frnog]

Le 28/08/2024 à 17:57, Lucas Viallon a écrit :

Je sollicite votre aide ;=) quelqu'un aurait un bout de config ASR1001X qui
marche
pour limiter le débit en OUT sur un vlan ?

J'ai une porte de collecte Orange CELAN 10G et pour un client qui a un lien
50Mbits
orange me dit que je pousse trop de flux, il faut que je limite a 50Mbits.

les config que j'ai trouvé ne fonctionnent pas pour le moment


Salut

Quelle type d'interface sur ton ASR ?

Quelle version IOS-XE ?

Tu veux limiter la casse avec du shaping et gérer des priorités ? ou tu 
veux écrêter sans distinction par policing ?


--
Jérôme Berthier

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

Re: [FRnOG] [ALERT] Messagerie ByTel mobile qui raccroche au bout de 33 secondes

[Jérôme RICHARD]

Bonjour,

Update sur le sujet : Bouygues aurait installé un correctif courant Août.
Effectivement, je ne constate plus le problème depuis quelques semaines.

Cordialement,
Jérôme RICHARD

Jérôme Richard

Directeur technique
[image: mobilePhone] 0698614239 / 0272240542
[image: emailAddress] jerome.rich...@va-telecom.fr 
[image: website] www.va-telecom.fr
[image: address] 3 rue du Tisserand, 44800, Nantes



Le jeu. 11 juil. 2024 à 22:43, Olivier GAUDET  a
écrit :

> Hello,
>
> Cette durée fait franchement penser au timer de 32s de raccroché pour
> non-réponse à une INVITE (INVITE transaction timeout timer) ou un truc du
> genre... ou alors le hasard fait bien les choses...
> Mais, si c'est bien ce cas, la piste VoLTE VS 2G/3G pourrait
> potentiellement expliquer (pur SIP en VoLTE...).
> Peut-être une piste...
>
> Cordialement,
>
> Olivier Gaudet
>
>
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Richard Klein
> Envoyé : jeudi 11 juillet 2024 14:36
> À : Alain Bieuzent 
> Cc : Nicolas Bougues ; Jérôme RICHARD <
> jerome.rich...@va-telecom.fr>; frnog-al...@frnog.org
> Objet : Re: [FRnOG] [ALERT] Messagerie ByTel mobile qui raccroche au bout
> de 33 secondes
>
> Si la messagerie raccroche car elle ne détecte pas de flux audio c'est
> qu'il y a un problème de communication blanche de l'appelant vers l'appelé.
> Lors de mes tests la première fois, j'ai dupliqué le problème.
> Mais comme je parlais doucement en main libre la messagerie a
> effectivement diffusé un message .
> Par contre le message est diffusé a 11s(et pas 33s) et la dame va dire :
> "vous n'avez rien enregistré".
> Il est important pour le support d'avoir ce type d'information car dans ce
> cas les investigations ne sont pas dans le même registre?
> Pour avoir effectué du support N2 mobile chez Bouygues pendant 5 ans voila
> les questions a se poser avant de faire des traces/investigations a partir
> des horodatages.
>
> Cordialement
>
> Richard
>
>
>
> Le jeu. 11 juil. 2024 à 14:06, Alain Bieuzent  a
> écrit :
>
> > Je partage l'analyse de Nicolas, il semblerai que la messagerie
> > "n'entende" aucun son et raccroche après 33 sec.
> >
> > Le 11/07/2024 14:04, « Nicolas Bougues »  > <mailto:frnog-requ...@frnog.org> au nom de nico...@bougues.net  > nico...@bougues.net>> a écrit :
> >
> >
> > Bonjour,
> >
> >
> > Souci analogue pour nous. On nous a parlé d'un souci de niveau sonore
> > avec le répondeur raccrochant croyant que l'audio est silencieuse.
> > Intéressé par toute info.
> >
> >
> >
> >
> > Le jeu. 11 juil. 2024 à 11:13, Jérôme RICHARD <
> > jerome.rich...@va-telecom.fr <mailto:jerome.rich...@va-telecom.fr>>
> > a écrit :
> >
> >
> > > Bonjour la liste,
> > >
> > > Depuis plusieurs mois on rencontre un phénomène sur une fraction de
> > > nos appels fixes sortants : Dans certains cas, quand l'utilisateur
> > > tombe sur
> > la
> > > messagerie d'un mobile ByTel, on reçoit un BYE (avec un Q850=127) au
> > > bout de 33 secondes après le OK.
> > >
> > > D'après notre transitaire, tous les cas que je leur communique
> > > concernent des numéros mobiles Bouygues. N'ayant pas la base EGP, je
> > > ne peux pas le vérifier.
> > >
> > > J'ai un ticket ouvert auprès de notre transitaire depuis bcp trop
> > longtemps
> > > qui nous dit qu'ils ont un ticket en cours + escalade auprès de
> > > Bouygues (qui aurait reconnu le pb) mais on avance à rien.
> > >
> > > Est-ce que nous sommes les seuls dans ce cas ?
> > >
> > > Cordialement,
> > > Jérôme RICHARD
> > >
> > > ---
> > > Liste de diffusion du FRnOG
> > > http://www.frnog.org/ <http://www.frnog.org/>
> > >
> >
> >
> >
> >
> > --
> > Nicolas Bougues
> >
> >
> > ---
> > 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] [BIZ] Cherche stack switches optique 24xSFP/ 4xSFP+

[Jérôme Berthier via frnog]

Le 04/09/2024 à 23:22, Jeremy a écrit :
Je te conseille de partir sur des switch Nexus 3064PQ-10GX, ça fera 
bien le job et ça coche toutes les cases. 


Salut,

Les Nexus c'est pas stackable (ou alors j'ai raté un truc).

Pour répondre à son besoin de 4 unités minimum, faudrait deux VPC 
interconnectés entre eux. A la fin, tu gères 4 switchs, pas une stack.


Je ne dis pas que c'est moins bien. :)

--
Jérôme Berthier


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

Re: [FRnOG] [TECH] Latence en France Aubervilliers / Lille

[Jérôme Marteaux]

Le 29/08/2024 à 12:49, damienl via frnog a écrit :

Bonjour David,


Oui il s'agit d'un opérateur national y'a très longtemps il avait des 
voitures bleues avec 3 lettres dessus. C'est le plus gros je pense en 
France.


EDF ?

--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] Latence en France Aubervilliers / Lille

[Jérôme Marteaux]

Le 29/08/2024 à 11:01, damienl via frnog a écrit :

Bonjour la liste,


Nous avons plusieurs sites interconnectés via un opérateur national.

Cet opérateur dispose de deux points de connexion un sur Aubervilliers 
et un sur Lille.



Suite à une mise en production, nous avons constaté que le DC situé en 
région parisienne joignait les sites connectés sur Aubervilliers en 9ms 
et ceux sur Lille en 18ms.



Nous avons ouvert un ticket et la première réponse c'est plus loin c'est 
plus long !


Le problème c'est que nous avons aussi un site situé dans une grande 
agglomération du Nord situé à 50km de Lille et la latence vers les sites 
connectés sur Lille sont aussi augmentés donc l'effet "distance" est 
hors sujet.


Après un second ticket et de nombreux échanges avec le support, le 
routeur a été changé pour le faire pointer vers Aubervilliers. La 
latence est bonne du coup mais le problème reste là pour les autres 
sites et le support ne voit pas de problème.


Le commercial parle d'offre sur mesure bref...


Quelle latence pour vous serait acceptable entre 2 sites en France ?



La latence dépend de 2 facteurs: la distance et le délai de traitement
des différents noeuds traversés (routeurs, switchs, firewall, modems
...).

Hormis cas particulier, le délai de traitement des noeuds est
aujourd'hui très faible, le facteur principal reste la distance.

Pour diagnostiquer le problème, tu peux faire un schéma où apparaîtront
tes 2 sites, comment ils sont connectés à ton opérateur, puis tu peux
demander à ton opérateur de compléter avec les liens qu'il a mis en
place pour connecter tes sites (collecte, transport, service).
Il faut aussi préciser si tu es sur Internet (si tes autres sites du
nord sont sur le même opérateur ou pas) ou dans un VPN/MPLS/SDWAN.

Pourquoi ça marche comme ça ?
L'objectif d'un opérateur c'est de mutualiser ces liens (collecte,
transport), par exemple si tu as 2 opérateurs qui vendent un lille
paris:
 - l'un a 1000 clients, il va pouvoir faire coût du lien lille-paris /
100 et vendre le lien 100 €
 - l'autre a 10 clients, il vendra son lien à 10 000 €
(le premier opérateur pourra aussi vendre le lien 1000 € et dégager une
marge pour construire un paris-lyon qui au début sera déficitaire car il
n'aura que peu de client dessus).

D'où l'intérêt pour un opérateur de charger un maximum son réseau et de
l'adapter en fonction des clients actuels et de la croissance espérée de
son parc client.

Si tu n'es pas satisfait de la partie "mutualisée" de ton opérateur,
celui-ci peut te proposer une solution sur-mesure, c'est à dire dédiée à
ton usage, l'intérêt c'est que tu auras une route directe car étudiée
pour ton besoin (et pas le besoin "moyen" de tous les clients de ton
opérateur) mais tu seras seul à en supporter le coût.

En général la latence aujourd'hui n'est pas un problème car les piles
TCP/IP des OS modernes arrivent tout à fait à s'en sortir pour obtenir
la capacité nominale des liens traversées quelque soit la latence. Les
produit "wan optimization" ne sont plus légion sur le marché.


Par curiosité quel est le problème soulevé par cette latence ? Tu fais
du high speed trading ? De la réplication NAS/SAN ?

Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] contributeurs pour tester notre assistant virtuel de Hotline

[Jérôme Nicolle]

Salut Lilian,

Le 13/08/2024 à 23:57, Lilian Coupat a écrit :
Certains d'entre vous ont relevé que la reconnaissance du mot "NON" lors 
des questions était laborieuse. En effet, dans les journaux de 
transcription, il était souvent transformé en "ON" ou "BON"


Il n'y a que max 1,2% de collision - en cas de dégradation sur un G.726 
ou G.729 surtout, qui confondent "positif" et "négatif". Sur un G.711 
propre j'en n'ai jamais vu. Adapter la terminologie est une piste 
d'amélioration à explorer, à mon humble avis.


Proposer des termes plus spécifiques au contexte marche globalement 
mieux il me semble.


@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

Re: [FRnOG] [TECH] 5mbits sur free

[Jérôme Nicolle]

Salut Béryl,

Le 03/08/2024 à 16:46, Béryl POUTHIER via frnog a écrit :

Je pense que c'est un soucis de capa sur peering et transit les
coupleurs son pas très charger par chez moi


Le taux de remplissage du coupleur ne change rien au partage de 
puissance par port. C'est simple en fait : soit tu reçoit dans les 2-3 
dB de plus que le seuil de sensibilité de ton ONU, soit il en chie à 
négocier et va foirer plus des 3/4 des trames.


Claque un power-meter en 1490 out 1330, en vrai si t'as pas le choix la 
valeur en 1310 standard est généralement assez proche, si t'as moins de 
-20dB t'es dans le rouge. Entre 15 et 18 t'es peinard. Plus de -12, t'es 
à peu près assis sur le NRO avec les taux de couplage classiques.



Après je doute que FRnOG soit un lieu pour parler d'opérateur grand
public vas plutôt chercher des infos sur lafibre.info.


Oui, il y a un peu plus de ressources sur le forum, mais ça fait jamais 
de mal de rappeler ici un peu que de la physique pas maitrisée sait 
causer plus de problème qu'un vendor claqué au sol. Si on sait pas 
mesurer, qualifier, tester et superviser juste deux valeurs de budget 
optique par lien, ils vont pas bien marcher longtemps nos réseaux.


Pour les trucs un peu plus touchy genre CDC en ROADM flexgrid, appuie 
toi sur ton vendor, ils sont presque tous sizés pour t'aider, surtout 
ceux d'Europe. Mais en vrai, si t'as des problèmes et pas de mecs à 
l'aise avec leurs cours de théorie du signal en dernière année dans ton 
équipe, t'aurais ptet pas du acheter ça.


@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

Re: [FRnOG] [ALERT] Incident GlobalSwitch

[Jérôme Marteaux]

Le 03/08/2024 à 14:52, Sébastien Aperghis-Tramoni via frnog a écrit :

Bonjour,


Mon premier message ici, pour informer que le DC GlobalSwitch semble à 
nouveau subir une panne majeure depuis au moins 12:38. Nous avons perdu 
l'accès à nos services là-bas. L'interconnexion réseau de notre 
opérateur a été perdue à 12:55.


GCP indique d'ailleurs une panne sur europe-west9-a : 
https://status.cloud.google.com/incidents/n71AYyDXgDVjZubZo8wu



Est-ce que d'autres personnes ici observent des problèmes similaires, 
voire ont de informations additionnelles




Coucou Sébastien !

Je confirme, mais ça vient de remonter depuis 5 minutes.
Apparemment ce serait un problème électrique.

Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [ALERT] Messagerie ByTel mobile qui raccroche au bout de 33 secondes

[Jérôme RICHARD]

A priori, les mobiles destination seraient en VOLTE selon ce qu'on m'a
remonté de Bouygues.

Pour les sonneries, j'ai les 2 cas, des appels qui tombent directement sur
la messagerie et d'autres avec environ 20 secondes de sonnerie (parfois
moins) avant de basculer sur le répondeur.

Cordialement,
Jérôme RICHARD

Jérôme Richard

Directeur technique
[image: mobilePhone] 0698614239 / 0272240542
[image: emailAddress] jerome.rich...@va-telecom.fr 
[image: website] www.va-telecom.fr
[image: address] 3 rue du Tisserand, 44800, Nantes



Le jeu. 11 juil. 2024 à 13:03, Richard Klein  a
écrit :

> Bonjour Jérôme,
>
> Lorsque tu dupliques il faudrait savoir si ton mobile passe par la VoLTE
> ou en 3G/2G, l'operateur que tu utilises pour faire l'appel.
> Autre chose lorsque tu vas émettre l'appel, tu tombes directement sur la
> messagerie ou elle s'enclenche après les 5 sonneries ?
>
> Cordialement
>
> Richard
>
>
>
>
> Le jeu. 11 juil. 2024 à 12:39, Jérôme RICHARD <
> jerome.rich...@va-telecom.fr> a écrit :
>
>> Bonjour Richard,
>>
>> En fait, je suis incapable de le reproduire car ça concerne qu'une
>> fraction des appels. Et je n'ai pas réussi à déterminer les critères qui
>> font qu'il apparaît. C'est pas faute d'avoir fait le jeu des 7 erreurs sur
>> les traces SIP... J'ai un de mes clients qui m'a remonté le problème puis
>> un autre. Avec les horodatages, j'ai pu observer le phénomène sur les
>> traces SIP.
>>
>> Donc je ne le reproduit pas mais je le constate tous les jours.
>>
>> Cordialement,
>> Jérôme RICHARD
>>
>> Jérôme Richard
>>
>> Directeur technique
>> [image: mobilePhone] 0698614239 / 0272240542
>> [image: emailAddress] jerome.rich...@va-telecom.fr 
>> [image: website] www.va-telecom.fr
>> [image: address] 3 rue du Tisserand, 44800, Nantes
>>
>>
>>
>> Le jeu. 11 juil. 2024 à 12:34, Richard Klein  a
>> écrit :
>>
>>> Bonjour a tous,
>>>
>>> Perso je ne duplique pas d'une ligne GP Bouygues vers la messagerie
>>> d'une ligne GP Bouygues.
>>> Tests effectué avec les deux telephones en VoLTE .
>>>
>>> Tu peux en dire plus sur ta configuration de test ?
>>>
>>> Bonne journée
>>>
>>> Richard
>>>
>>>
>>> Le jeu. 11 juil. 2024 à 11:58, Jérôme RICHARD <
>>> jerome.rich...@va-telecom.fr> a écrit :
>>>
>>>> Bonjour Alain,
>>>>
>>>> Merci pour ton message. Je me sens moins seul ;)
>>>>
>>>> Si en plus Bouygues se bouge ce sera bô.
>>>>
>>>> Cordialement,
>>>> Jérôme RICHARD
>>>>
>>>>
>>>>
>>>> Le jeu. 11 juil. 2024 à 11:29, Alain Bieuzent 
>>>> a
>>>> écrit :
>>>>
>>>> > Bonjour Jérôme,
>>>> >
>>>> > Merci d'avoir alerté, nous ne l'avions pas repéré.
>>>> > Je confirme le défaut (nous avons interco directe avec Bouygues).
>>>> >
>>>> > J'ouvre un ticket à ce propos chez Bouygues, je vous tiens au courant.
>>>> >
>>>> > Cordialement.
>>>> >
>>>> > Le 11/07/2024 11:13, « Jérôme RICHARD » >>> >>> > frnog-requ...@frnog.org> au nom de jerome.rich...@va-telecom.fr
>>>> >>> > jerome.rich...@va-telecom.fr>> a écrit :
>>>> >
>>>> >
>>>> > Bonjour la liste,
>>>> >
>>>> >
>>>> > Depuis plusieurs mois on rencontre un phénomène sur une fraction de
>>>> nos
>>>> > appels fixes sortants : Dans certains cas, quand l'utilisateur tombe
>>>> sur la
>>>> > messagerie d'un mobile ByTel, on reçoit un BYE (avec un Q850=127) au
>>>> bout
>>>> > de 33 secondes après le OK.
>>>> >
>>>> >
>>>> > D'après notre transitaire, tous les cas que je leur communique
>>>> concernent
>>>> > des numéros mobiles Bouygues. N'ayant pas la base EGP, je ne peux pas
>>>> le
>>>> > vérifier.
>>>> >
>>>> >
>>>> > J'ai un ticket ouvert auprès de notre transitaire depuis bcp trop
>>>> longtemps
>>>> > qui nous dit qu'ils ont un ticket en cours + escalade auprès de
>>>> Bouygues
>>>> > (qui aurait reconnu le pb) mais on avance à rien.
>>>> >
>>>> >
>>>> > Est-ce que nous sommes les seuls dans ce cas ?
>>>> >
>>>> >
>>>> > Cordialement,
>>>> > Jérôme RICHARD
>>>> >
>>>> >
>>>> > ---
>>>> > 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] [ALERT] Messagerie ByTel mobile qui raccroche au bout de 33 secondes

[Jérôme RICHARD]

Bonjour Richard,

En fait, je suis incapable de le reproduire car ça concerne qu'une fraction
des appels. Et je n'ai pas réussi à déterminer les critères qui font qu'il
apparaît. C'est pas faute d'avoir fait le jeu des 7 erreurs sur les traces
SIP... J'ai un de mes clients qui m'a remonté le problème puis un autre.
Avec les horodatages, j'ai pu observer le phénomène sur les traces SIP.

Donc je ne le reproduit pas mais je le constate tous les jours.

Cordialement,
Jérôme RICHARD

Jérôme Richard

Directeur technique
[image: mobilePhone] 0698614239 / 0272240542
[image: emailAddress] jerome.rich...@va-telecom.fr 
[image: website] www.va-telecom.fr
[image: address] 3 rue du Tisserand, 44800, Nantes



Le jeu. 11 juil. 2024 à 12:34, Richard Klein  a
écrit :

> Bonjour a tous,
>
> Perso je ne duplique pas d'une ligne GP Bouygues vers la messagerie d'une
> ligne GP Bouygues.
> Tests effectué avec les deux telephones en VoLTE .
>
> Tu peux en dire plus sur ta configuration de test ?
>
> Bonne journée
>
> Richard
>
>
> Le jeu. 11 juil. 2024 à 11:58, Jérôme RICHARD <
> jerome.rich...@va-telecom.fr> a écrit :
>
>> Bonjour Alain,
>>
>> Merci pour ton message. Je me sens moins seul ;)
>>
>> Si en plus Bouygues se bouge ce sera bô.
>>
>> Cordialement,
>> Jérôme RICHARD
>>
>>
>>
>> Le jeu. 11 juil. 2024 à 11:29, Alain Bieuzent  a
>> écrit :
>>
>> > Bonjour Jérôme,
>> >
>> > Merci d'avoir alerté, nous ne l'avions pas repéré.
>> > Je confirme le défaut (nous avons interco directe avec Bouygues).
>> >
>> > J'ouvre un ticket à ce propos chez Bouygues, je vous tiens au courant.
>> >
>> > Cordialement.
>> >
>> > Le 11/07/2024 11:13, « Jérôme RICHARD » > > > frnog-requ...@frnog.org> au nom de jerome.rich...@va-telecom.fr
>> > > jerome.rich...@va-telecom.fr>> a écrit :
>> >
>> >
>> > Bonjour la liste,
>> >
>> >
>> > Depuis plusieurs mois on rencontre un phénomène sur une fraction de nos
>> > appels fixes sortants : Dans certains cas, quand l'utilisateur tombe
>> sur la
>> > messagerie d'un mobile ByTel, on reçoit un BYE (avec un Q850=127) au
>> bout
>> > de 33 secondes après le OK.
>> >
>> >
>> > D'après notre transitaire, tous les cas que je leur communique
>> concernent
>> > des numéros mobiles Bouygues. N'ayant pas la base EGP, je ne peux pas le
>> > vérifier.
>> >
>> >
>> > J'ai un ticket ouvert auprès de notre transitaire depuis bcp trop
>> longtemps
>> > qui nous dit qu'ils ont un ticket en cours + escalade auprès de Bouygues
>> > (qui aurait reconnu le pb) mais on avance à rien.
>> >
>> >
>> > Est-ce que nous sommes les seuls dans ce cas ?
>> >
>> >
>> > Cordialement,
>> > Jérôme RICHARD
>> >
>> >
>> > ---
>> > 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] [ALERT] Messagerie ByTel mobile qui raccroche au bout de 33 secondes

[Jérôme RICHARD]

Bonjour Alain,

Merci pour ton message. Je me sens moins seul ;)

Si en plus Bouygues se bouge ce sera bô.

Cordialement,
Jérôme RICHARD



Le jeu. 11 juil. 2024 à 11:29, Alain Bieuzent  a
écrit :

> Bonjour Jérôme,
>
> Merci d'avoir alerté, nous ne l'avions pas repéré.
> Je confirme le défaut (nous avons interco directe avec Bouygues).
>
> J'ouvre un ticket à ce propos chez Bouygues, je vous tiens au courant.
>
> Cordialement.
>
> Le 11/07/2024 11:13, « Jérôme RICHARD »  frnog-requ...@frnog.org> au nom de jerome.rich...@va-telecom.fr  jerome.rich...@va-telecom.fr>> a écrit :
>
>
> Bonjour la liste,
>
>
> Depuis plusieurs mois on rencontre un phénomène sur une fraction de nos
> appels fixes sortants : Dans certains cas, quand l'utilisateur tombe sur la
> messagerie d'un mobile ByTel, on reçoit un BYE (avec un Q850=127) au bout
> de 33 secondes après le OK.
>
>
> D'après notre transitaire, tous les cas que je leur communique concernent
> des numéros mobiles Bouygues. N'ayant pas la base EGP, je ne peux pas le
> vérifier.
>
>
> J'ai un ticket ouvert auprès de notre transitaire depuis bcp trop longtemps
> qui nous dit qu'ils ont un ticket en cours + escalade auprès de Bouygues
> (qui aurait reconnu le pb) mais on avance à rien.
>
>
> Est-ce que nous sommes les seuls dans ce cas ?
>
>
> Cordialement,
> Jérôme RICHARD
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ <http://www.frnog.org/>
>
>
>
>
>

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

[FRnOG] [ALERT] Messagerie ByTel mobile qui raccroche au bout de 33 secondes

[Jérôme RICHARD]

Bonjour la liste,

Depuis plusieurs mois on rencontre un phénomène sur une fraction de nos
appels fixes sortants : Dans certains cas, quand l'utilisateur tombe sur la
messagerie d'un mobile ByTel, on reçoit un BYE (avec un Q850=127) au bout
de 33 secondes après le OK.

D'après notre transitaire, tous les cas que je leur communique concernent
des numéros mobiles Bouygues. N'ayant pas la base EGP, je ne peux pas le
vérifier.

J'ai un ticket ouvert auprès de notre transitaire depuis bcp trop longtemps
qui nous dit qu'ils ont un ticket en cours + escalade auprès de Bouygues
(qui aurait reconnu le pb) mais on avance à rien.

Est-ce que nous sommes les seuls dans ce cas ?

Cordialement,
Jérôme RICHARD

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

Re: [FRnOG] [MISC] - DDos assisté par Mikrotik

[Jérôme Marteaux]

Le 09/07/2024 à 18:00, Laurent-Charles FABRE a écrit :

Bonjour la liste,

l'article doit exister en français mais je suis tombé sur la version
Britonne

https://blog.ovhcloud.com/the-rise-of-packet-rate-attacks-when-core-routers-turn-evil/

De votre compréhension, c'est un gros trou dans RouteurOS ou une misconfig
basique avec MdP troué ?



SNMP n'est pas activé par défaut sur mikrotik:
v6: https://wiki.mikrotik.com/wiki/Manual:SNMP
v7: https://help.mikrotik.com/docs/display/ROS/SNMP

Il y a de (très) fortes chances que ce soit un SNMP qui soit ouvert.
La mode est d'utiliser de l'amplification (reflexion), SNMP se prête 
bien à ce jeu, à partir d'une requête de 68 octets, la réponse peut 
aller jusqu'à 30 Ko, j'ai lu qu'en moyenne il était observé un rapport 
de 1:25 en faveur de l'attaquant. (si l'attaquant dispose de 100 Mbps de 
bande passante, il va pouvoir envoyer 2,5 Gbps de réponses SNMP sur l'IP 
ciblée)

Pour en savoir plus: https://www.bortzmeyer.org/attaques-reflexion.html

Si l'attaque est faite via SNMP qui donc est ouvert, c'est alors tout 
simple de faire une requête pour afficher le modèle et sa version.


Quant aux routeurs dont le SNMP n'est pas ouvert en public, il reste 
possible que ces routeurs aient une ACL qui limite l'accès à SNMP au LAN 
mais si les machines derrières sont compromises, il est aisé de faire de 
l'amplification SNMP et renvoyer le trafic sur le WAN, en plus comme 
c'est le routeur qui émet le trafic ça bypass les règles de firewall car 
en général le trafic émit par le firewall est toujours autorisés (au 
moins sur les mikrotik, chaîne output en default policy accept versus 
forward dont la bonne pratique doit être default deny).



Par contre, j'ai un doute avec le contenu du dernier paragraphe "Let’s 
do some math" car ça m'étonnerait qu'un mikrotik (ou tout autre 
équipement) ai un service SNMP qui soit capable de sortir autant de pps 
qu'en routage pur. (Multi-threadé ? Sur tous les core ? Avec 1 seule IP 
de sortie ?)


H on n'avait pas ce genre de problème avec des SUP720 ou des ISR 
avec des CPU anémiques ! C'était mieux avant !


Maintenant avec des tp-link, mikrotik et compagnie qui ont des CPU 
surpuissants (comme nos téléphones), tout est possible !



Par contre, j'en retire au moins ça :
- les CCR poussent quand même pas mal


Le rapport perf/prix est imbattable !


- ils en vendent pas mal en chine...



Mais que fait le great firewall chinois ?? Depuis internet vers la chine 
ça à l'air efficace mais en sortie tout est permis !



Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] Conseil petit routeur n wan

[Jérôme Nicolle]

Hello Stéphane,

Ccr 1009 sous RoS7 est clairement une option. Tu peux tenter autre chose mais 
ça risquerait de prendre plus de temps à faire tomber en marche.

@+

Le 5 juillet 2024 14:34:39 GMT+02:00, "Stéphane Rivière"  a 
écrit :
>Bonjour à toutes et tous,
>
>Pour une manip, j'aurais besoin d'un routeur éco :
>minimum 2 WAN et 3 idéal,
>minimum 3 LAN, 5 idéal
>(donc 5 à 8 ETH au total, ce qui n'est pas chose si courante)
>et qui cause OpenVPN dans le texte
>
>Fonctionnalités basiques, une isolation sur les ETH LAN serait un plus
>
>Sans investissement pour la config si possible (du web irait bien).
>
>Je préférerais éviter Netgear et Zyxel.
>
>Ce genre de Mikrotik pourrait aller je suppose et je crois qu'on peut y poser 
>un OpenWRT
>
>https://www.getic.fr/product/mikrotik-rb5009ug-s-in?vat_state=incl¤cy=EUR&gads=idealo_fr
>
>C'est plus mon taff de tous les jours et je m'en remet à vos conseils :)
>
>Merci d'avance
>
>-- 
>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] [BIZ] une demande et des propositions de dons

[Jérôme Nicolle]

Salut Pierre,

Le 04/07/2024 à 09:12, Pierre DOLIDON a écrit :

pourquoi pas par satellite ?


Alors c'est un truc que je regarde de près depuis que je bosse aux Antilles.

Sur Saint-Barth, on a eu plus de 1000 kits Starlink livrés d'après DHL. 
Impossible d'avoir un chiffre exact. La ground-station de référence est 
Porto-Rico, faute d'accords avec les autres territoires (et c'est pas 
faute d'avoir proposé).


Le problème c'est la "souveraineté" et l'harmonisation de la solution. 
Sur Saint-Barth et Saint-Martin, on a le droitl'ARCEP a dit oui. Sur 
Sint-Maarten, Saba, Statia et St-Kitts & Nevis on peut pas, par exemple 
: pas de validation des régulateurs locaux (ils ont fait sécession des NL).


On a pas d'autre acteur de lien SAT à peu près compétitif, surtout pas 
EU, donc on est cuits sur cette zone.


Il faut faire gaffe à ce qu'on demande, peut-être que consolider les 
infras fixes d'abord est un meilleur pari.


@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

[FRnOG] [MISC] Changement de composition du board de France-IX association

[Jérôme Nicolle]

Bonjour,

Juste pour vous tenir au jus, je ne fais plus partie du board de 
l'association Franck-IX depuis ce midi.


Sans rentrer dans les détails, on avait trop de divergences : je voulais 
représenter ceux qui m'ont élu et traiter des sujets à la racine, pas en 
surface. C'était pas compatible avec un rôle d'administrateur qui se 
devrait d'être plus distant, en tout cas dans le principe des status 
actuels.


On continuera à travailler tous ensemble pour l'objet principal : 
promouvoir l'interconnexion, mais je peux maintenant passer plus de 
temps sur des projets régionaux et fonctionnels nouveaux.


Les compositions actuelles du board et du CoStra vous seront 
communiquées par l'association prochainement. Pensez à adhérer pour y 
avoir votre mot à dire !


À très bientôt sur un switch près de chez vous ! Et à la prochaine AG !

@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

Re: [FRnOG] [MISC] TF1 streaming vire les clients lents ?

[Jérôme Nicolle]

Simon,

Le 27/06/2024 à 13:09, Simon Laroque a écrit :

En effet, on ne communique pas sur ces détails.


Je comprends que tu fasses partie des soumis aux ayant-tous-les-droits. 
Mais en terme de debug technique on a besoin de savoir quelles 
cochoncetés vous faites, pour aider les clients illégitimement bloqués 
par vos anti-services.


OK, on ne peut que demander gentiment. Ou bien on demande à l'ARCOM 
pourquoi il y a de la discrimination d'audimat légitime pour cause 
d'excessivité des conséquences d'une protection soit-disant technique 
pour préserver les ayant-tous-les-droits ?


Je dis pas que j'ai envie de me frotter à ces clowns, mais vous me posez 
des problèmes en outre-mer aussi, et là ça va barder. Avec un chapeau.


@+

P.S. 'cule un mouton.

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

Re: [FRnOG] [MISC] Décès d'un confrère

[Jérôme Nicolle]

Xavier,

Le 25/06/2024 à 16:19, Xavier Beaudouin via frnog a écrit :

Outre ce point qui est important, et quand j'ai appris le bazar que Jérome et
Clément ont gérés (et peut-être pas finis) suite au décès de Manuel, je me
pose la question par rapport à ma famille.


T'en fais pas c'est fini. L'actionnaire scélérat a tué la boîte, on a 
juste sauvé les clients qu'on pouvait. Mais c'est pas juste Clément et 
moi, Guillaume et Cécile ont bien aidé. Je sais pas pour les suivants, 
ils ne sont pas en état d'esprit coopératif et bossaient sciemment pour 
une ordure.


Sur ce cas particulier il n'y avait aucune disposition de prise. Tout 
reposait sur une personne, et on n'a pu reprendre la main que parce que 
sa machine principale était encore opérationnelle avec la clef SSH 
débloquée.


Quand il y a eu une coupure de jus on avait déjà repris la main sur 90% 
du parc. Ensuite on a eu plus de mal.


C'est sans compter le SI custom sur lequel je n'ai trouvé que 5 
personnes au monde compétentes sur le framework, pas toutes disponibles. 
C'était plus simple de reconstruire la compta avec des outils standards.


De la récup en milieu hostile, c'est vraiment compliqué à faire, surtout 
sur des boîtes à haut bus-factor. Coup de bol cette fois ça a marché 
jusqu'à une malveillance humaine. C'est pas garanti pour d'autres 
structures.


Comptez bien la charge de reprise de vos SI dans vos 
disaster-recovery-plans SVP. C'est vraiment difficile de repasser derrière.


@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

Re: [FRnOG] [MISC] TF1 streaming vire les clients lents ?

[Jérôme Nicolle]

Bonjour Simon,

Le 26/06/2024 à 11:57, Simon Laroque a écrit :

détection des
VPNs


Genre PMTUd ? Ou simplement blocklists ?

Si basé sur le MTU, quelles sont les plages considérées comme acceptables ?

@+

--
Jérôme Nicolle
+33 6 19 31 27 14


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

[FRnOG] [MISC] Décès d'un confrère

[Jérôme Nicolle]

Bonsoir,

J'ai appris cet après-midi le décès d'Arnaud Rouzade, d'un AVC à 50 ans, 
jeudi dernier.


Ses obsèques se tiendront à Boulogne mercredi. Samuel Triolet y sera 
présent. Je vais essayer, faites moi signe pour ceux qui veulent venir.


L'équipe a forcement besoin d'un peu de temps pour tout reprendre, mais 
la boîte est solide et bien gérée, donc on n'a pas à s'inquiéter d'un 
gros shift opérationnel.


Selon les dires de ses plus proches, on n'a pas vraiment besoin de 
fleurs périssables pour orner sa tombe. Par contre on devra s'occuper de 
Olga, sa veuve, qui se retrouve en difficulté.


Un peu comme Catherine, suite au décès de Manuel Guesdon. Dites, les 
gars, on se ferait pas une mutuelle/prévoyance sectorielle franchement ?


@+

--
Jérôme Nicolle
+33 6 19 31 27 14


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

Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Jérôme RICHARD]

> AMHA, laisser à un client final la liberté de couper des appels de
manière trop restrictive et infondée, ça serait > un cauchemar pour les
Services Clients des opérateurs.

Effectivement. On fait quoi de cette note A/B/C ?

Cordialement,
Jérôme RICHARD

Jérôme Richard

Directeur technique
[image: mobilePhone] 0698614239 / 0272240542
[image: emailAddress] jerome.rich...@va-telecom.fr 
[image: website] www.va-telecom.fr
[image: address] 3 rue du Tisserand, 44800, Nantes



Le ven. 21 juin 2024 à 12:41, David Ponzone  a
écrit :

> AMHA, laisser à un client final la liberté de couper des appels de manière
> trop restrictive et infondée, ça serait un cauchemar pour les Services
> Clients des opérateurs.
>
> David
>
> > Le 21 juin 2024 à 12:36, Jérôme RICHARD 
> a écrit :
> >
> > Pour l'identity je suis Ok.
> >
> > Pour l'info d'attestation je n'avais pas vu l'info. C'est dommage de ne
> pas
> > le transmettre je trouve.
> >
> > Cordialement,
> > Jérôme RICHARD
> >
> >
> >
> >
> > Le ven. 21 juin 2024 à 12:03, Alain Bieuzent  a
> > écrit :
> >
> >> Bonjour Jérôme,
> >>
> >> L'APNF a clairement précisé qu'il était interdit de transmettre l'entête
> >> Identity aux client finaux (cela reste de l'info inter-opérateur) et
> qu'il
> >> était aussi interdit de transmettre le niveau d'attestation (quel que
> soit
> >> la manière utilisée).
> >>
> >> Alain
> >>
> >> Le 21/06/2024 11:53, « Jérôme RICHARD »   >> frnog-requ...@frnog.org> au nom de jerome.rich...@va-telecom.fr
>  >> jerome.rich...@va-telecom.fr>> a écrit :
> >>
> >>
> >> Bonjour,
> >>
> >>
> >> Le MAN ajoute un entête identity assez conséquent (plus de 500 octet) à
> >> l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et donc
> de la
> >> fragmentation ce qui n'est pas supporté par tous les IPBX. Le symptôme
> que
> >> j'ai pu constater c'est que l'IPBX destinataire ne répond pas aux INVITE
> >> avec entête identity.
> >>
> >>
> >> Nous avons fait le choix de ne pas le diffuser vers les trunks de nos
> >> clients puisque nous réalisons le contrôle en amont et de diffuser
> >> uniquement le Attestation-Info (A, B ou C) qui en ressort.
> >>
> >>
> >> Donc a voir si les appels qui posent problème ont l'entête identity dans
> >> l'INVITE.
> >>
> >>
> >> Cordialement,
> >> Jérôme RICHARD
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog <
> frnog@frnog.org
> >> <mailto:frnog@frnog.org>> a
> >> écrit :
> >>
> >>
> >>> On est les seuls à être très, TRES, impacté par la mise en place du man
> >>> chez alphalink depuis plusieurs jours ?
> >>> On a du mal à identifier l'origine du problème : dans certains cas cela
> >>> semble être un problème de MTU et de paquet SIP fragmenté, d'autres cas
> >>> sont plus obscurs...
> >>> Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est
> >> un
> >>> cas isolé ?
> >>> Comment souvent : communication proche du 0, au début quand on a
> remonté
> >>> les soucis on nous a gentiment envoyé balader genre « c'est pas notre
> >>> probleme », et maintenant ça semble être la panique.
> >>>
> >>>
> >>>
> >>> Cordialement,
> >>>
> >>>
> >>> [cid:image001.png@01DAC3C1.1D673B20]
> >>> Olivier Varenne
> >>> Président, R&D et développement
> >>> T +33 (0)4 27 04 40 00 | ipconnect.fr<http://www.ipconnect.fr/> <
> >> http://www.ipconnect.fr/>;>
> >>>
> >>> Suivez-nous !
> >>> [picto-twitter]<https://twitter.com/ip_connectweets> <
> >> https://twitter.com/ip_connectweets>;>[picto-youtube]<
> >>> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug> <
> >> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>
> >> ;>[picto-linkedin]<
> >>> https://www.linkedin.com/company/20541473/admin/> <
> >> https://www.linkedin.com/company/20541473/admin/>;>
> >>>
> >>>
> >>> ---
> >>> 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/

Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Jérôme RICHARD]

Pour l'identity je suis Ok.

Pour l'info d'attestation je n'avais pas vu l'info. C'est dommage de ne pas
le transmettre je trouve.

Cordialement,
Jérôme RICHARD




Le ven. 21 juin 2024 à 12:03, Alain Bieuzent  a
écrit :

> Bonjour Jérôme,
>
> L'APNF a clairement précisé qu'il était interdit de transmettre l'entête
> Identity aux client finaux (cela reste de l'info inter-opérateur) et qu'il
> était aussi interdit de transmettre le niveau d'attestation (quel que soit
> la manière utilisée).
>
> Alain
>
> Le 21/06/2024 11:53, « Jérôme RICHARD »  frnog-requ...@frnog.org> au nom de jerome.rich...@va-telecom.fr  jerome.rich...@va-telecom.fr>> a écrit :
>
>
> Bonjour,
>
>
> Le MAN ajoute un entête identity assez conséquent (plus de 500 octet) à
> l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et donc de la
> fragmentation ce qui n'est pas supporté par tous les IPBX. Le symptôme que
> j'ai pu constater c'est que l'IPBX destinataire ne répond pas aux INVITE
> avec entête identity.
>
>
> Nous avons fait le choix de ne pas le diffuser vers les trunks de nos
> clients puisque nous réalisons le contrôle en amont et de diffuser
> uniquement le Attestation-Info (A, B ou C) qui en ressort.
>
>
> Donc a voir si les appels qui posent problème ont l'entête identity dans
> l'INVITE.
>
>
> Cordialement,
> Jérôme RICHARD
>
>
>
>
>
>
>
>
> Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog  <mailto:frnog@frnog.org>> a
> écrit :
>
>
> > On est les seuls à être très, TRES, impacté par la mise en place du man
> > chez alphalink depuis plusieurs jours ?
> > On a du mal à identifier l'origine du problème : dans certains cas cela
> > semble être un problème de MTU et de paquet SIP fragmenté, d'autres cas
> > sont plus obscurs...
> > Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est
> un
> > cas isolé ?
> > Comment souvent : communication proche du 0, au début quand on a remonté
> > les soucis on nous a gentiment envoyé balader genre « c'est pas notre
> > probleme », et maintenant ça semble être la panique.
> >
> >
> >
> > Cordialement,
> >
> >
> > [cid:image001.png@01DAC3C1.1D673B20]
> > Olivier Varenne
> > Président, R&D et développement
> > T +33 (0)4 27 04 40 00 | ipconnect.fr<http://www.ipconnect.fr/> <
> http://www.ipconnect.fr/>;>
> >
> > Suivez-nous !
> > [picto-twitter]<https://twitter.com/ip_connectweets> <
> https://twitter.com/ip_connectweets>;>[picto-youtube]<
> > https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug> <
> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>
> ;>[picto-linkedin]<
> > https://www.linkedin.com/company/20541473/admin/> <
> https://www.linkedin.com/company/20541473/admin/>;>
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/ <http://www.frnog.org/>
> >
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ <http://www.frnog.org/>
>
>
>
>
>

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

Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Jérôme RICHARD]

Bonjour,

Le MAN ajoute un entête identity assez conséquent (plus de 500 octet) à
l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et donc de la
fragmentation ce qui n'est pas supporté par tous les IPBX. Le symptôme que
j'ai pu constater c'est que l'IPBX destinataire ne répond pas aux INVITE
avec entête identity.

Nous avons fait le choix de ne pas le diffuser vers les trunks de nos
clients puisque nous réalisons le contrôle en amont et de diffuser
uniquement le Attestation-Info (A, B ou C) qui en ressort.

Donc a voir si les appels qui posent problème ont l'entête identity dans
l'INVITE.

Cordialement,
Jérôme RICHARD




Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog  a
écrit :

> On est les seuls à être très, TRES, impacté par la mise en place du man
> chez alphalink depuis plusieurs jours ?
> On a du mal à identifier l'origine du problème : dans certains cas cela
> semble être un problème de MTU et de paquet SIP fragmenté, d'autres cas
> sont plus obscurs...
> Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est un
> cas isolé ?
> Comment souvent : communication proche du 0, au début quand on a remonté
> les soucis on nous a gentiment envoyé balader genre « c'est pas notre
> probleme », et maintenant ça semble être la panique.
>
>
>
> Cordialement,
>
>
> [cid:image001.png@01DAC3C1.1D673B20]
> Olivier Varenne
> Président, R&D et développement
> T +33 (0)4 27 04 40 00 | ipconnect.fr<http://www.ipconnect.fr/>
>
> Suivez-nous !
> [picto-twitter]<https://twitter.com/ip_connectweets>[picto-youtube]<
> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>[picto-linkedin]<
> https://www.linkedin.com/company/20541473/admin/>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Bgp sous FRR

[Jérôme Marteaux]

Bonjour,

Le 20/06/2024 à 11:19, Laurent CARON a écrit :

Bonjour,

J'ai eu le cas la semaine dernière chez l'agrume (5511).

Livraison de 2 sessions BGP4 pour lesquelles le traceroute/MTR est 
systématiquement menteur (toutes les destinations sont directement 
connectées au nexthop), seul port non filtré en sortie tcp/179 (bgp).




Quel est l'intérêt de ce "filtrage" ?
Et comment c'est réalisé ?


En entrée en revanche, aucun filtrage.

La solution a été de passer par agrume {inde,pologne,france} ("bah oui 
m'sieur, nos gros clients sont majoritairement à l'international") pour 
changer de bloc d'interco pour un qui ne dispose pas de ces filtres...




Juste le bloc d'interco ou changement de service/plaque/produit IP ?


Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [MISC] AG France-IX du 12 juin

[Jérôme Nicolle]

Hello !

L'AG c'est aujourd'hui ! Je n'y serais pas, je suis encore en mission 
trop loin de Paris. Désolé. Mais j'ai voté en ligne, ça se passe là : 
https://franceix-asso.org/vote/ .


Tous les votants ont du recevoir les informations par mail. Faites le 
s'il vous plaît, on a besoin de vous pour définir l'avenir de l'association.


Je m'abstiendrai de toute recommandation de vote, contrairement à 
certains confrères en ayant profité pour publier du FUD dommageable à 
tout le monde.


En fait, j'aime bien tous les candidats, je dirais même qu'on a un panel 
exceptionnel. C'est très prometteur !


Au plaisir de vous revoir dès mon retour en métropole,

@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

Re: [FRnOG] [TECH] Arista pour full-table ?

[Jérôme Nicolle]

IC,

Le 06/06/2024 à 15:56, ic a écrit :

1M tu ne vas pas tenir longtemps sachant qu’on approche les 950k…


Ouais alors attends. Quand on flirtait avec les 512k routes on a bien 
trouvé des astuces pour maintenir des 6500 en prod. J'en connais même 
qui ont maintenu des 7500 après le passage des 256k routes.


Les oursins dans la poche des patrons non techs ont la peau dure, on 
commence à avoir l'habitude.


@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

Re: [FRnOG] [TECH] Collecte Ethernet Operateur - Routeurs suggèrerés de nos jours

[Jérôme Nicolle]

David,

Le 07/06/2024 à 11:26, David Ponzone a écrit :

6Wind BNG 🙂


Tiens, ça me fait poser une question : si tu fais tourner ton vRouter 
chez Amazon - ou autres - comment tu y récupères ton trunk de collecte ?


Non parce qu'in est en 2024, on est bien censé dématérialiser les 
réseaux, non ?


@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

[FRnOG] [MISC] AG France-IX du 12 juin

[Jérôme Nicolle]

Bonjour à tous,

TL;DR: adhérez à l'association France-IX pour voter à l'AG du 12 juin !

Pour les membres de l'association France-IX, vous en avez déjà été 
informés. Pour ceux qui ne sont pas encore membres (ce n'est plus 
automatique depuis un bout de temps) il serait temps de vous mettre à la 
page.


Ce 12 juin 2024 se tient la prochaine AG de l'association, qui possède 
et "pilote" la société qui opère le point d'échange. 
https://franceix-asso.org/actualites/assemblee-generale-du-12-juin-2024/


Aussi https://franceix-asso.org/events/ag-240612/ . Comme il en est de 
coutume, l'AG sera suivie d'un aPEERo auquel vous pouvez vous inscrire 
là : https://franceix-asso.org/events/apeero-002/ .


(Bon en vrai ce sera le #3 vu qu'on en a un à Saint-Martin ce vendredi, 
mais c'est pas pareil, loin des yeux…).


Alors, je sais, l'association et la société, c'est un modèle compliqué, 
mais qui a pour but que la communauté - vous - puisse décider de ce 
qu'il s'y passe. On l'a monté comme ça il y a 16 ans, c'est pas pour rien.


Cette année est un peu particulière, à plus d'un titre. On a modifié les 
status l'année dernière pour assurer une meilleure représentation de la 
communauté et compartimenter les sujets opérationnels chiants qui 
n'intéressent personne. Donc on joue avec des règles un peu différentes 
maintenant, néanmoins plus proches de l'esprit initial de 2008.


Il y a cette année une élections de nouveaux membres du bureau : trois 
sont sortants, on en ouvre un quatrième, et je suis menacé d'éviction 
pour avoir trop travaillé et pas mis les formes. Donc il y a quatre 
postes à pourvoir pour rester à 7 ou monter à 8 membres du conseil 
d'administration. On avait ouvert les candidatures sur 
https://franceix-asso.org/actualites/election-membres-du-conseil-dadministration-de-france-ix-association/ 
.


Les candidatures sont finalisées, ils sont huit, c'est maintenant aux 
membres de choisir. Normalement les membres ont reçu la liste, si vous 
avez un doute regardez mes contacts Linked-In ou Twitter. Ou bien DM.


Si vous n'êtes pas encore membre, il n'est pas trop tard, il y a un 
formulaire pour ça sur le site. 
https://franceix-asso.org/a-propos/adherer-a-l-association/


Si vous voulez que ça bouge, alors votez pour les gens en qui vous 
croyez. Pensez à voter ce dimanche 9 aussi. Pour ceux qui me suivent sur 
twiXter c'est facile d'avoir une recommandation en cas de doute.


@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

Re: Re :Re: [FRnOG] [MISC] Digression du Vendredi sur l'identité numérique

[Jérôme Marteaux]

Le 31/05/2024 à 22:18, Votre Opérateur Local a écrit :

Bonsoir,

Petite anecdote sur le processus de validation avec l'application l'identité 
numérique par la poste.

Je suis allé récupérer 1 AR qui n'avait pu m'être distribué, étant en 
déplacement ce jour-là.

Ayant oublié ma cni physique, j'ai proposé la cipie du document stocké sur mon 
instance nextcloud:
"Ah mais, c'est pas possible, sans l'application..."

Que j'ai fait installé devant lui
Puis validé avec le même document...
et enfin sécurisé via un sms sur ma ligne voip virtuelle, avec son collègue au 
comptoir sur son smartphone.

Puis, j'ai récupéré ma lettre AR !

en lui expliquant que le sms arrivait simultanément sur mon pc, tablette et 2e 
smartphone ayant l'application de téléphonie ...

Bref, un "non sens" au final, puisque j'ai validé une identité numérique réelle 
avec un document virtuel présenté.

A part ca, tout va bien dans le meilleur des mondes.

Bon week-end à tous


Pas tout à fait d'accord.

C'est rassurant de savoir que des gens respectent les procédures.

Mais est-ce que l'application la poste ne vérifierait pas les
"numéros/identifiants" de la CNI avec une/des autre(s) base(s) de
données permettant de s'assurer que le document/la copie présenté(e)
est un vrai ?
Le rôle du tiers de confiance a tout son intérêt ici.

Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] "Suspicion de spam" sur appels téléphoniques légitimes ?

[Jérôme Marteaux]

Le 31/05/2024 à 09:29, Toussaint OTTAVI a écrit :


Le 30/05/2024 à 22:37, Jérôme Marteaux a écrit :
Si ça devenait moins rentable comme métier, la pratique s'arrêterait 
d'elle-même pour basculer vers un autre secteur. 


... qui continuera de nous harceler sur nos téléphones !

D'autant plus que, même si les nouvelles normes se mettent en place, et 
que l'identification et la traçabilité des appelants arrivent à être 
clairement établies, la frontière entre "démarchage", "abus de 
crédulité" et "hameçonnage" restera assez floue...


Tu as cerné le point important, c'est sur cette frontière qu'est le nœud 
du problème.




A la rigueur, cela permettra peut-être la création de bases de données 
fiables de publicitaires/démarcheurs, et le développement d'outils 
anti-publicité /anti-pollution aussi efficaces que ceux que nous avons 
déjà sur nos navigateurs web...




C'est une illusion, je ne vois pas ce que le MAN pourrait apporté de ce 
côté-là.


En attendant, si je ne veux pas rater d'appels importants, je suis 
condamné à décrocher chaque fois que mon téléphone sonne. Ma technique à 
moi, c'est de répondre : "Désolé, je ne parle pas Français". En langue 
Corse. :-D


C'est une solution, n'y-aurai-t'il pas des "démarcheurs" corse ?!

--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] "Suspicion de spam" sur appels téléphoniques légitimes ?

[Jérôme Marteaux]

Le 30/05/2024 à 22:30, David Ponzone a écrit :

Pour info, j’ai fait une stat aujourd’hui, j’ai environ 5% des appels entrants 
(vers des clients pro seulement) qui sont du démarchage. Tous bloqués bien sûr.
Et c’est quand même souvent da la merde comme démarchage.
Ca fait un gros gâchis de ressources pour tenter de fourguer des panneaux 
solaires à un mec en appart.


C'est que les marges doivent être bonnes !
Si ça devenait moins rentable comme métier, la pratique s'arrêterait 
d'elle-même pour basculer vers un autre secteur.


Jérôme


Le 30 mai 2024 à 22:00, Jerome Marteaux  a écrit :

Le 30/05/2024 à 15:10, Toussaint OTTAVI a écrit :

Le 30/05/2024 à 14:41, Julien Issler a écrit :

Si tu es sûr que c'est du démarchage, tu peux toujours décrocher en
faisant "commissariat/gendarmerie bonjour" j'imagine que ça peut en
calmer certains :⁠-⁠)

J'aime bien aussi : "Ne quittez pas...", puis mettre le micro en silence, et 
poser le téléphone dans un coin :-)
Mais si c'est un robot, çà ne marche pas :-)


Il y a une autre astuce, comme ces gens utilisent des bases de données
de numéros non qualifiés il y a énormément de déchet, donc pour gaver
leurs "agents" d'un maximum d'appel ils utilisent un robot d'appel en
mode prédictif, c'est à dire que le robot va composer 5 numéros
simultanément, en moyenne 2 seront cassés car pas attribués, 2 seront
sur répondeur et 1 répondra, il passera alors cette communication à
l'agent. Selon le nombre d'agent et la "qualité" de la base de données,
le nombre de numéro appelés simultanément varie.

Le problème c'est la détection du répondeur, si le robot passe un
répondeur à l'agent celui-ci va perdre du temps (et potentiellement
rester en ligne un maximum de temps car ça va compter pour un appel
qualifié, ie un appel où l'agent aura déroulé tout son script).

Mais le robot est comme nous, il ne sait pas s'il parle à quelqu'un ou
si c'est un répondeur (pas d'information dans la signalisation).
Pour détecter ce répondeur, le robot va écouter les 2 premières secondes
de la communication, si pas de son alors il va penser que c'est le
répondeur qui décroche et va raccrocher à son tour. Car en général le
SVI du répondeur met quelques secondes à embrayer sur le message
d'absence.

Donc quand tu décroche tu fais le silence pendant 2 secondes et ça
raccrochera. L'inconvénient c'est que le robot essayera de rappeler car
le numéro sera noté comme attribué donc un numéro valide, une chance de
plus pour joindre un potentiel pigeon !

Tous les opérateurs reçoivent tous les jours des listes d'abuses sur des
appels et SMS suspicieux mais ...

Le législateur essaye de légiférer depuis tellement d'années (CPCE,
LCEN, bloctel, nouvelle loi en 2020, MAN ...).
En face il y a essentiellement la FEVAD (Fédération du e-commerce et de
la vente à distance) qui s'est opposée de toutes ces forces aux efforts
du législateur pour réguler et encadrer ces appels, leur principal
argument est que les encadrements proposés (par les associations de
consommateurs, parlementaires ...) empêcherait ainsi les gens de
travailler et ainsi que ça mettrait beaucoup de gens au chômage.
Allez voir leur site web, il y a un truc sur la pub dans les boîtes au
lettre, mais rien sur les appels téléphoniques.

Les victimes ont connus une seule victoire: le spam par fax est terminé
! Faut-il supprimer le téléphone ? Déjà les jeunes ne téléphonent plus,
donc bientôt que des forfaits data only et qu'avec des appli OTP ?

Jérôme


--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] Bgp sous FRR

[Jérôme Marteaux]

Le 26/05/2024 à 19:07, Raphael Mazelier a écrit :

On 26/05/2024 18:33, Nicolas wrote:


Non, mais l'ip n'est pas routé en publique donc elle ne passe pas : d'où
mon pb


Des ip(s) d'interco publiques mais non routé sur internet ? c'est peu pratique 
et étonnant.


Cette astuce permet de réduire la surface d'attaque mais n'est pas aisé 
pour troubleshooter si on ne se trouve pas à l'intérieur de l'un des 
deux réseaux impliqués. Ce n'est pas très répandu, mais c'est encore 
pratiqué.



Sinon à partir du moment ou tu as une IPs (une loopback ?) publique 
correctement routé vers ton routeur tu peux l’utiliser pour communiquer depuis 
ton routeur.

Comme tu es sous linux n'importe quel bricolage à coup de iptables fonctionnera. Après 
est ce que tu peux le "configurer" depuis FRR ?



Une loopback est en effet une bonne solution !


Jérôme

--
Jérôme Marteaux



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

Re: [FRnOG] [MISC] Identité numérique pour l'accès aux datacenters

[Jérôme Nicolle]

Tiens, j'en profite parce que je suis jamais certain de l'acronyme.

Le 24/05/2024 à 11:04, Toussaint OTTAVI a écrit :

mode "CASSOS"


C'est bien Cap gemini, Atos, Sopra, Steria, Orange ? Mais le dernier je 
suis pas sûr ?


@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

Re: [FRnOG] [MISC] Identité numérique pour l'accès aux datacenters

[Jérôme Nicolle]

David,

Le 24/05/2024 à 11:43, David Ponzone a écrit :

C’était quoi le problème en fait d’utiliser les Impôts ou Ameli, pour
FranceConnect+, dès le départ ?


J'aime bien le fait que ce soit une preuve manifeste du rapprochement de 
tous les fichiers de l'État, soit précisément ce contre quoi la CNIL a 
été crée en 1978. Les temps ont changés, notre APD est en état de mort 
cérébrale.



Pire, qu’est-ce qui justifie de créer un FranceConnect+, pour accéder à 3
  services pas spécialement critiques, à part un vrai désir de
complexification administrative, ou alors une guerre de clocher interne ?


Franchement, quand il marche, le service est la démonstration de 
l'ambition d'un des plus grand SSO public au monde ! C'est beau hein ? 
C'est français, môssieur.



C’est quoi le problème qui empêche d’avoir une app web, pour ceux qui
refusent une app venant du store officiel ?


Nan mais déjà qu'ils ne savent pas acheter à des agences qui savent 
coder proprement du web classique, s'il en reste, c'est quand même 
vachement plus simple de faire une app de 100Mo bourrée de trackers par 
défaut dans le framework pour n'importe quel service.


Tiens, on pourrait savoir combien de place les apps d'état et colterr 
pèsent pour leur reprocher de pousser à l'obsolescence programmer des 
terminaux ?


@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

Re: [FRnOG] [MISC] Identité numérique pour l'accès aux datacenters

[Jérôme Nicolle]

Laurent,

Le 22/05/2024 à 16:58, Laurent Bloch a écrit :

Il semblerait que cela ne marche pas avec Murena et /e/os, seulement
avec les systèmes et les magasins d'applications officiels.


Ça fonctionne très bien sur GrapheneOS en l'installant via Aurora Store. 
C'était un prérequis pour moi de pouvoir fonctionner sur un appareil 
dégooglisé.


@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

[FRnOG] [MISC] Identité numérique pour l'accès aux datacenters

[Jérôme Nicolle]

Bonjour,

On en parle peu mais l'application France Identité permet de "charger" 
votre carte d'identité nouveau format sur votre téléphone. De plus en 
plus de services utilisent ce mode d'authentification. Par exemple j'ai 
pu à l'instant faire une procuration de vote sans me déplacer pour la 
faire valider.


Mais quid de l'accès en datacenter ou tout autre lieu demandant une 
pièce d'identité ? Est ce qu'on va pouvoir simplement montrer l'écran du 
téléphone ? Utiliser le process d'authentification via l'application en 
scannant un QR Code ?


Pour aller encore plus loin, au sommet Digital Alliance EU-LAC la 
semaine dernière on a travaillé sur l'interopérabilité de l'identité 
numérique avec des pays non européens. Quand serons nous prêts à 
utiliser plus généralement ce système ?


@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

Re: [FRnOG] [TECH] Problème FortiGate

[Jérôme Marteaux]

Le 16/05/2024 à 09:34, Toussaint OTTAVI a écrit :



Le 15/05/2024 à 14:48, Hugues Voiturier a écrit :
Mais quelle excellente idée de changer la MTU de l’interface sans 
changer la MSS,


Je suppose que cela dépend des équipements. MSS = MTU moins les headers 
(IP, TCP, IPsec...). Par défaut, le matériel que j'utilise calcule la 
MSS tout seul en fonction de la MTU spécifiée. A vérifier dans la doc du 
firewall, mais s'il ne le fait pas automatiquement, si on réduit la MTU, 
il faut à priori réduire aussi la MSS à MTU - 40 (20 octets de header 
TCP + 20 octets de header IP)


--
Sinon, à ma connaissance, il n'y a pas de risque à spécifier une MTU (et 
une MSS) trop petite (à part bien sûr la fragmentation excessive, qui 
peut dégrader les performances).


Ce n'est pas une bonne idée. Exemple avec ce schéma:
CPE <--> PE

Si la MTU du PE est à 1500 et celle du CPE est à 1492: lorsque le PE va 
envoyer des paquets à 1500 le CPE va les dropper.
Et surtout le drop n'émet pas un paquet ICMP, donc si c'est du TCP la 
pile TCP doit interpréter ce drop comme un problème de MTU et pas une 
perte de paquet "classique", d'où le long délai pour établir une 
connexion (qui plus est en HTTPS avec la session SSL).


Et inversement PE / CPE.

La MTU doit toujours être identique des 2 côtés et il n'y a pas d'autre 
possibilité.


$ ping -M do -s xxx ip

peut parfaitement détecter des problèmes de MTU.



1492 est la valeur classique d'une MTU sur un lien WAN PPPoE.
Avec certains opérateurs, et en fonction de la façon dont ils collectent 
le trafic pour le ramener sur leur infra, on peut être amenés à 
descendre la MTU jusqu'à 1452 pour que le trafic passe bien.


Ca c'est un problème, car la MTU est négociée par le PPPoE, est-ce que 
ton routeur a bien pris en compte la négo PPPoE ?
Le LNS lui va envoyer des paquets à la MTU sans savoir que ton CPE a une 
MTU beaucoup petite.




Pour ce que j'ai pu en voir, on n'a besoin de modifier la MTU que si 
l'on monte soi-même la session PPPoE. Si l'opérateur fournit un routeur, 
c'est lui qui se débrouille, et on garde une MTU normale de 1500 sur 
l'interface Ethernet.




Normalement en IPv4 les routeurs fragmentent, à charge au destinataire 
de ré-assembler. Donc si c'est bien fait, le CPE doit arriver à 
fragmenter correctement.
En IPv6 c'est l'émetteur qui doit fragmenter avant d'envoyer les paquets 
(d'où l'importance du PMTUd et de laisser passer ICMP).


Jérôme

--
Jérôme Marteaux



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

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

[Jérôme Marteaux]

Le 07/05/2024 à 11:08, David Ponzone a écrit :

J’ai des forts doutes sur la capacité du MVNO-Light à faire bouger Orange, ou 
même répondre.

Ceci dit, si Philippe a le problème avec des cartes Orange Pro, et moi avec des 
cartes MVNO-Light, c’est que c’est un problème inhérent à l’infra complète 
Orange Mobile, dans le contexte Fortinet/Forticlient.


Détrompe toi, chaque MVNO-light a ces propres règles de firewalling chez 
Orange qu'il peut faire évoluer.
Orange Pro et MVNO-light ne partage pas la même infra, mais probablement 
les mêmes modèles d'équipements avec les mêmes versions d'où les 
problèmes identiques.




J’ai de nombreux Mikrotik qui montent des tunnels IKEv2 à travers les mêmes 
cartes MVNO-Light vers du Fortinet, sans problème.


Probablement un ALG qui se déclenche spécifiquement sur le trafic fortinet ?


Ca pourrait donc être lié aussi au MTU négocié par IOS avec Orange.

Si Philippe peut tester avec Android pour voir….

David


Le 6 mai 2024 à 22:15, Jérôme Marteaux  a écrit :

Si tu as accès au support du MVNO-light, remonte-leur le problème, il est 
possible qu'il y ai un firewall sur le chemin dont l'ALG ou l'inspection de 
paquet pose problème.

Jérôme

Le 06/05/2024 à 21:42, David Ponzone a écrit :

Comme je l’ai posté il y a quelques jours, j’ai reproduit le problème de 
Philippe, avec un MVNO-Light Orange (donc techniquement, c’est Orange, CGNAT 
Orange, c’est même normalement plus propre).
Par contre, mon APN, aucune idée :)
David

Le 6 mai 2024 à 19:49, Jérôme Marteaux  a écrit :

Le 06/05/2024 à 11:54, Philippe ASTIER via frnog a écrit :

Bonjour !
En fait, c’est pas compliqué, ça passe juste plus du tout chez Orange Pro 
Mobile.
Et en 2024, devoir bricoler des APNs ou des MTU pour que ça marche, c’est une 
honte absolue. Intéressant intellectuellement pour comprendre, mais 
inadmissible en production.
Tu changes d’opérateur ou tu essaies en Wifi, et hop, connecté en quelques 
centaines de millisecondes.
Je suis en discussion avec le client pour savoir ce qu’on met en priorité: 
accélération du déploiement de la solution ZTNA, quitte à mettre de eSIM 
d’opérateurs alternatifs pour qu’on puisse terminer le projet.

Le 6 mai 2024 à 11:46, Thierry Chich  a écrit :

Bonjour



Par curiosité c'est Orange en direct ou via un revendeur ?
L'IP publique appartient à Orange ?
Quel est le nom de l'APN ?


--
Jérôme Marteaux


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

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

[Jérôme Marteaux]

Si tu as accès au support du MVNO-light, remonte-leur le problème, il 
est possible qu'il y ai un firewall sur le chemin dont l'ALG ou 
l'inspection de paquet pose problème.


Jérôme

Le 06/05/2024 à 21:42, David Ponzone a écrit :

Comme je l’ai posté il y a quelques jours, j’ai reproduit le problème de 
Philippe, avec un MVNO-Light Orange (donc techniquement, c’est Orange, CGNAT 
Orange, c’est même normalement plus propre).
Par contre, mon APN, aucune idée :)

David



Le 6 mai 2024 à 19:49, Jérôme Marteaux  a écrit :

Le 06/05/2024 à 11:54, Philippe ASTIER via frnog a écrit :

Bonjour !
En fait, c’est pas compliqué, ça passe juste plus du tout chez Orange Pro 
Mobile.
Et en 2024, devoir bricoler des APNs ou des MTU pour que ça marche, c’est une 
honte absolue. Intéressant intellectuellement pour comprendre, mais 
inadmissible en production.
Tu changes d’opérateur ou tu essaies en Wifi, et hop, connecté en quelques 
centaines de millisecondes.
Je suis en discussion avec le client pour savoir ce qu’on met en priorité: 
accélération du déploiement de la solution ZTNA, quitte à mettre de eSIM 
d’opérateurs alternatifs pour qu’on puisse terminer le projet.

Le 6 mai 2024 à 11:46, Thierry Chich  a écrit :

Bonjour



Par curiosité c'est Orange en direct ou via un revendeur ?
L'IP publique appartient à Orange ?
Quel est le nom de l'APN ?

Jérôme



--
Jérôme Marteaux


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

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

[Jérôme Marteaux]

Le 06/05/2024 à 11:54, Philippe ASTIER via frnog a écrit :

Bonjour !

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

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


Le 6 mai 2024 à 11:46, Thierry Chich  a écrit :

Bonjour



Par curiosité c'est Orange en direct ou via un revendeur ?
L'IP publique appartient à Orange ?
Quel est le nom de l'APN ?

Jérôme

--
Jérôme Marteaux


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

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

[Jérôme Marteaux]

Le 02/05/2024 à 19:34, Toussaint OTTAVI a écrit :


Le 02/05/2024 à 12:48, Philippe ASTIER via frnog a écrit :

Depuis quelques mois (dur à retracer), chez un seul client, impossible
de monter un tunnel IPSec via iOS ou macOS quand ils sont en 4G/5G (sur
le device ou en partage de connexion).
Avec la même configuration, la connexion en wifi/ethernet depuis
n’importe quel autre opérateur fonctionne sans souci.


J'utilise une autre marque de firewalls, mais il m'arrive parfois de 
constater ce phénomène. Parfois, çà se produit sur certaines connexions 
en partage 4G/5G (pas toutes). D'autres fois, derrière une Livebox, çà 
passe en Ethernet, mais çà ne passe pas en WiFi. Il n'y a pas de règle 
absolue...


Il y a longtemps, je m'étais amusé à faire des captures de paquets :
- IKE, c'est de l'UDP. Lorsque le premier paquet est trop gros, il est 
fragmenté
- Coté destination, les fragments arrivent "dans le mauvais ordre" (mais 
pourquoi ???)
- Le ré-assemblage des fragments ne se fait pas, et cela empêche la 
négociation IKE de démarrer


Les conditions dans lesquelles un paquet IKE a besoin d'être fragmenté 
et/ou les paquets arrivent dans le désordre,  je ne les connais pas 
vraiment.  En revanche, dans mon client VPN logiciel (d'une autre 
marque, je le rappelle), il y a une option "Restrict the size of the 
first ISAKMP packet sent". Depuis que cette option existe (je dirais un 
an ou deux), lorsque le problème se produit, elle permet de le résoudre.


Hope this helps...


Peut-être est-ce une application précoce de:
https://www.lemonde.fr/pixels/article/2024/04/22/europol-s-oppose-au-chiffrement-des-messageries_6229195_4408996.html

Le VPN ne fonctionnant plus, il faut passer que ça passe en clair ! :)

--
Jérôme Marteaux



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

Re: [FRnOG] [MISC] Fwd: France-IX launches its new Transit IP service!

[Jérôme Nicolle]

Salut Jehan,

Sujet intéressant mais opaque et complexe.

En fonction des volumes et des options (anti-ddos, allocations de blocs, 
sessions eBGP multihop pour le RTBH…) en France métropolitaine tu vas 
être entre 0,1 et 3€/Mbps (commit mini 1G, 'faut pas déconner). 
Attention, si tu payes des cacahuètes t'as souvent du transit de qualité 
discutable. Genre juste la moitié du monde IPv6.


En APAC ou dans les îles d'Outre-Mer, t'es plutôt à entre 3 et 15€/Mbps, 
parce que comme Pierre-Yves l'a très bien expliqué dans ses deux 
dernières présentations au FRnOG, les câbles sous-marins, c'est chiant.


Le 13/03/2024 à 21:34, jehan procaccia INT a écrit :
j'aimerai savoir quand notre contrat va arriver a terme s'il faut 
chercher ailleurs/renegocier, ou si finalement les prix sont uniformes 
sur la place parisienne (DC3) par exemple aujourd'hui je suis a 500€ HT 
pour 1G, est-ce normal ou je me fais avoir ...? quelle est la tendance ?


T'es dans les clous à ce prix là, pour une qualité moyenne à bonne. Si 
tu essayes de raboter là dessus je penses que tu vas commencer à taper 
dans le mauvais - en tout cas pour certains trafics.


Et franchement sur DC3 tu vas avoir deux voire trois acteurs qui se 
démarquent sur le qualitatif ET le prix pour du trafic francophone. Pas 
besoin de chercher loin.


@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

Re: [FRnOG] [TECH]

[Jérôme Berthier via frnog]

Le 14/03/2024 à 17:59, donkish...@neuf.fr via frnog a écrit :
Existerait-il une solution de pont à base de wifi6(E) par exemple 
(j'aimerais bien dans les 1 à 10Gb/s stable sans latence pour 
l'interlink), qui serait un minimum orientable (pour ne pas trop 
perturber notre wifi d'entreprise) avec j'imagine un seul SSID pour 
maximiser les performances dans lequel nous pourrions faire passer les 
vlan de notre choix ?
Cela pourrait-il se faire avec une solution standard type Meraki pour 
un résultat satisfaisant similaire à une solution dédié en mettant 
juste une borne au plafond de chaque côté de la porte coup feu du 
plateau ? 


Salut,

Y a du passage au niveau de cette porte coupe feu ? elle est ouverte 
sauf détection incendie ? tu as suffisamment de hauteur pour mettre les 
AP en vis à vis sans obstacle dans leur champ (genre Michel de la compta 
avec ses trois mugs de café) ?


Je connais pas plus que ça mais Meraki semble bien proposer du bridging 
mesh : 
https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Extending_the_LAN_with_a_Wireless_Mesh_Link


Par curiosité, lu en travers (je connais pas :) ), il y a des 
dépendances entre la version soft et la possibilité de bridger plusieurs 
vlans sinon faut du L3 en aval du bridge et router sur l'uplink.


Pour le modèle de bornes, a priori, tous les modèles supportent le mesh 
: 
https://documentation.meraki.com/MR/Deployment_Guides/Mesh_Deployment_Guide#Access_Point_Capabilities


Il me semble qu'il vaut mieux éviter d'utiliser des AP standard avec 
antenne omni. Il faut des AP mesh avec antenne directionnelle (enfin ça 
parait préférable). En Wi-Fi 6E, tu as le modèle CW9166D1 qui intègre 
une antenne directionnelle.


Bon courage

--
Jérôme Berthier


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

Re: [FRnOG] [TECH] Configuration VPN sur Cisco

[Jérôme Berthier via frnog]

Le 12/03/2024 à 10:53, Lionel Giraudeau-Bocquet via frnog a écrit :
- trouver le moyen de récupérer le numéro du vlan en provenance de la 
MAC de la carte IPMI (et je suis certain que le switch a l'info 
quelque part, je ne sais juste pas comment lui faire cracher le morceau) 


Utiliser la fonction "Packet capture" intégrée au switch 3650 ?

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/37e/consolidated_guide/b_37e_consolidated_3650_cg/b_37e_consolidated_3650_cg_chapter_0110001.html

--
Jérôme Berthier


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

Re: [FRnOG] [TECH] Configuration VPN sur Cisco

[Jérôme Marteaux]

Le 12/03/2024 à 10:53, Lionel Giraudeau-Bocquet via frnog a écrit :

Bonjour à tous,

Membre de FDN j'ai déjà posé cette question sur une liste sympa interne 
et il m'a été conseillé de venir poser ma question ici (merci tout de 
même !).


Voici le problème que je n'arrive pas à résoudre :
J'ai récupéré plusieurs lames (ayant une carte IPMI qui est intégrée à 
la carte mère) qui ont été installées dans un chassis avec d'autres que 
j'avais déjà.
Le panneau de contrôle du châssis me permet de faire des power on/off et 
récupérer les adresses MAC des cartes Ethernet et IPMI.
J'ai mis du temps à comprendre pourquoi les cartes IPMI ne demandaient 
pas d'adresse au serveur DHCP sur le réseau : ces cartes ont été 
configurées avec une adresse IP fixe dans un VLAN au pif (== que je ne 
connais pas)

Elles ne causent donc pas avec le vlan natif Cisco (vlan 1).

Je m'en suis sorti, à distance et avec de la chance, car les lames 
tentent de booter en PXE avant d'essayer leur disque. J'ai donc 
configurer le serveur PXE pour leur envoyer une image de dépannage sur 
laquelle elles ont booté et j'ai pu faire un "ipmitool lan set 1 vlan id 
off". Dans la seconde les cartes IPMI obtiennent leur adresse IP.


Belle histoire, mais ce n'est pas fini : l'une des lames ne parvient pas 
à démarrer (soit elle boot sur son disque interne automatiquement et se 
retrouve donc avec une adresse IP fixe que je ne connais pas, soit elle 
joue aux dames, soit elle est coincée au boot dans le Bios ou autre, 
soit la carte mère est tout simplement morte ).
Pour parvenir à savoir ce qu'il se passe je suis obligé de passer par la 
carte IPMI (pas de port pour brancher un écran et encore moins un clavier).


La lame est connectée (via le switch du chassis qui ne fait que 
transmettre les paquets sans toucher aux ID vlan) au port Gi1/0/11 d'un 
Cisco, et le serveur DHCP sur le port Gi1/0/6.
Les ports Gi1/0/[1-20] et Gi1/1/[1-24] (c'est une stack de deux switchs) 
sont dans le vlan 1, les 4 derniers du premier switch (Gi1/0/[21-24]) 
sont dans le vlan 2. Les deux vlans ne communiquent pas, il y a juste 
une machine qui a une patte sur ce vlan 1 privé et l'autre sur un réseau 
auquel j'ai accès à distance.


Dans un monde idéal, je cherche à ce que, temporairement, carte IPMI et 
serveur DHCP se causent pour que la première ait une adresse IP et que 
du deuxième je parvienne à lancer un ipmitool (je connais user et mot de 
passe) pour virer ce vlan dont je ne connais pas le numéro.


Je vois ça "simplement" comme ça :
- trouver le moyen de récupérer le numéro du vlan en provenance de la 
MAC de la carte IPMI (et je suis certain que le switch a l'info quelque 
part, je ne sais juste pas comment lui faire cracher le morceau)


Sur le port Gi1/0/11 tu met un vlan isolé que tu propage jusqu'à ta 
machine qui a 2 pattes, tu fais un tcpdump sur ce vlan avec -e pour 
qu'il te montre le vlan utilisé par la lame lorsqu'elle fera ces 
requêtes DHCP.
-e c'est pour montrer le détail du layer 2 et notamment les vlan 
utilisés (même si le 1er vlan est encapsulé dans un 2ème (q-in-q)).



- peut-on faire une règle sur le port 11 qui dit que tout paquet qui 
arrive de cette MAC se voit attribuer le vlan 1

- tout paquet à destination de la MAC se voit attribuer le vlan XXX


Je ne connais pas de matériel qui sait faire ça.


Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] Clavier non fonctionnel au démarrage d'un HP Proliant DL360 gen7

[Jérôme Nicolle]

David,

Le 11/03/2024 à 15:11, David Ponzone a écrit :

Plutôt pour FRSAG je pense ?


Plutôt la poubelle hein. Un Gen7 c'est compliqué d'en justifier la 
consommation pour des perfs à la hauteur d'un SBC moderne.


@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

Re: [FRnOG] [MISC] Meta HS quelqu'un a de l'info ?

[Jérôme Nicolle]

David,

Le 08/03/2024 à 17:32, David Ponzone a écrit :

Euh on est autonomes pour produire tout ce qu’il faut pour faire marcher du 
mobile ?


En stockant des puces asiatiques ou en se sortant les doigts pour 
pouvoir en produire localement oui. Les PCB et l'assemblage on sait le 
faire en Europe. Les antennes aussi.



Tu penses qu’en 4 ans, on pourrait devenir autonomes et produire ce qu’il faut 
pour ré-équiper des dizaines de millier de BTS ?


Non, quelques milliers. Les zones blanches des bouseux on verra plus 
tard, comme d'habitude.



Je suis un peu dubitatif.
Je pense personnellement que ça se jouera à celui qui a le plus de $ sur le 
tarmac de l’aéroport de Shenzen.


Parce que tu crois que les avions actuellement en service peuvent voler 
sans satellites ?



Et les DC, ils vont prendre ça comment ?
On peut pas s’attendre à quelques incendies ?


Les vrais en béton épais ça va le faire. Les cellules en bacacier n'ont 
pas besoin d'un Carrington pour brûler.


Mais bon, un Carrington conduirait plus probablement au scénario de 
Ravage, de Barjavel. Les survivants auront de fortes chances de s'en 
prendre violemment contre toute tentative de recréer l'arbre 
technologique actuel.


Savez-vous planter des choux ?

@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

Re: [FRnOG] [MISC] Meta HS quelqu'un a de l'info ?

[Jérôme Nicolle]

Bonjour Jean,

Chouette sujet, merci de l'engager.

Le 08/03/2024 à 14:49, Jean Lilensten a écrit :
Avant de m'en retirer (je n'ai pas compris comment 
procéder d'ailleurs : les modérateurs pourront-ils m'y aider ?), je 
souhaite donc m'adresser à vous.


Mets un filtre pour mettre les mails dans un sous-dossier à regarder 
et/ou vider de temps en temps, et garde un œil dessus, il s'y passe 
parfois des choses intéressantes et instructives.


Avez-vous eu connaissances de pannes de réseaux, de pannes 
informatiques, ou électroniques dont l'origine aurait pu être attribuée 
à l'activité solaire ?


En réseaux terrestres non. Tout ce qu'on peut observer sont des pics de 
bruit sur les signaux de certains satellites quand la ionosphère est un 
peu secouée.


Si vous travaillez pour un opérateur, avez-vous des plans particuliers 
face à ce risque ? Avez-vous pris des précautions spéciales ?


Non, et ça n'aurait aucun intérêt de tenter de se prémunir 
spécifiquement contre ce risque.


Déjà parce qu'il y a une impossibilité logistique et économique à 
dimensionner le pire des cas, et surtout parce que le jour où on n'en 
aurait besoin, la plupart des petites mains qui font tourner les réseaux 
seraient probablement plus occuper à sauver leur propre peau que leurs 
réseaux.


Si un Carrington Event se produisait aujourd'hui, c'est la grille 
électrique qui sauterait en premier. Pas de numérique sans électricité, 
et même si les groupes électrogène des salles machines marchent encore, 
les utilisateurs non.


Les réseaux cuivre aérien ou mal enfouis crameraient aussi probablement, 
avec leurs équipements d'extrémité. On n'a plus l'habitude de garder du 
spare pour ces vielles brelles, en France en tout cas.


Sur la radio, les antennes et préamplis prendraient tellement cher qu'il 
faudrait tout remplacer. Compte au moins 4 ans de production en mode 
économie de guerre pour y arriver. Par contre ça forcerait les MNO à 
être moins cons qu'actuellement et à mutualiser plus et mieux leurs 
infrastructures.


Sur la fibre, rien à craindre. Câbles comme machines sont relativement 
immunes contre le risque électromagnétique. Sauf peut être les BMH et 
Landing Points des câbles sous-marin, dans lesquels on a toujours des 
conducteurs pour injecter du courant modulé afin de les localiser, 
repêcher et réparer, même quand il n'y a pas de répéteurs.


Quelles que soient vos réponses, m'autorisez-vous à les partager avec 
mes collègues (si vous me communiquez des choses sensibles ou 
confidentielles, précisez-le, c'est important). Et même, dites-moi si 
vous m'autorisez à les publier (pas dans des articles scientifiques, 
mais dans des articles grand public ou un livre en préparation). Je cite 
toujours mes sources, et si vous m'y autorisez, je vous citerai donc !


Ça devrait être connu plus largement, donc vas-y, propos en CC0 pour ma 
part.


@+

--
Jérôme Nicolle
+33 6 19 31 27 14
+590 690 22 87 14


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

Re: [FRnOG] [MISC] Meta HS quelqu'un a de l'info ?

[Jérôme Marteaux]

Le 08/03/2024 à 10:46, Stéphane Rivière a écrit :

Le 07/03/2024 à 19:12, l...@netc.fr a écrit :

>Au delà de l'aspect kikoulol de Meta, je vous rappelle néanmoins que ce
groupe permet à des milliers d'entreprises de faire vivre de nombreuses
équipes partout dans le monde > Par ailleurs on fait pas mal de CA avec Meta 
puisqu'on est (à la base)
une agence Web. On a un KAM attribué par Meta, comme le Gougle 
d'ailleurs. Donc on n'est pas des haineux, on les utilise comme ils nous 
utilisent, c'est le biz. Mais fondamentalement, ils ne font vivre qu'eux 
mêmes et on s'en passerait bien car dans un écosystème imaginaire (c'est 
à dire honnête et non biaisé), on pourrait faire beaucoup mieux et 
augmenter encore notre CA sur le marketing de contenu (par exemple). Ces 
monopoles sont juste des freins.


késako un KAM ?

--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] Le KVM ultime…

[GROS Jérôme]

Bonjour,

Il faut un logiciel sur les phériphériques cibles, non ? Je vois Windaube/Mac 
Android/iOS.
Est-qu'il fonctionne sous Linux ?

Merci d'avance.

Le 26/02/24 01:21, Jeremy a écrit :

Commandé, testé et validé depuis quelques semaines.
Jérémy
Le 26/02/2024 à 01:05, David Ponzone a écrit :

Depuis le temps que j’attendais ça:

https://www.aurga.com/products/aurga-viewer?utm_source=facebook&utm_medium=paid&utm_campaign=g01&fbclid=IwAR0jKSYQSrfkBGBkquGXQ8Ky2XUGEsT-ZMOnpsQDr0T_P0k4sHx9Chu7UU0_aem_AUkJnidbtsXdJUB5za9Jv0ZJ8tcdkfEie5frGfist82-wcrkddGWRDDurf7howEQar8

David Ponzone



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

Re: [FRnOG] [TECH] TDF, ça rime avec TNT, moins avec FTTH

[Jérôme Nicolle]

David,

Le 23/02/2024 à 11:19, David Ponzone a écrit :

soit parce qu’on leur a dit de jamais dire qu’ils avaient construit leur réseau 
FTTH sur du Mikrotik


Il faudrait arrêter le Mikrotik-bashing. Il y a des bugs, comme chez 
tous les autres. Il y a des manques de fonctionnalités, mais beaucoup 
moins que chez les autres. Ils consomment beaucoup moins que les autres.


Le problème est juste que peu de gens savent s'en servir correctement. 
C'est moins "standard" comme approche. Mais quand tu fais correctement 
ton job avec, ça juste marche.


De mon point de vue on est pas loin du stade où si tu bash Mikrotik sans 
réelle justification technique, c'est toi le nul.


@+

--
Jérôme Nicolle
+33 6 19 31 27 14


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

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

[Jérôme Marteaux]

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

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

J’aime beaucoup le « temporaire ».



Tout va bien: 
https://techreport.com/news/microsoft-azure-hit-with-the-largest-data-breach-in-its-history-hundreds-of-executive-accounts-compromised/


J'espère que les agents et l'ANSSI qui vont travailler dessus sont plus 
vigilants et plus efficaces qu'un commissaire aux comptes.
Est-on vraiment sûr que ce que raconte Microsoft sur Azure est bien la 
réalité, un truc vraiment sûr (au sens de sûreté) ?



Jérôme

--
Jérôme Marteaux


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

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

[Jérôme Marteaux]

 n'a pas permis de révolutionner quoique ce 
soit, ipv6 devait apporter le roaming (ipv6 mobile): 
http://wapiti.enic.fr/commun/ens/peda/options/ST/RIO/pub/exposes/exposesrio2008/Traore-Werquin/Mobile%20IPv6.html

qui implémente ça ?
Côté sécurité aussi (IPSEC embedded), j'ai pas l'impression que c'est 
vachement utilisé.


Et une 5ème: le même groupe de travail aurait pu ré-implémenter UDP et 
TCP en même temps, ça à l'air tout has-been, aujourd'hui avec HTTP/2 , 
QUIC et JSON on fait presque tout.




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

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


Je persiste à dire que notre éco-système est très dynamique et permet à 
des choses invraisemblables d'apparaître, des licornes de se monter (que 
certaines font pschi en engloutissant les millions des derniers 
entrants). Il y a des bonnes choses qui en sont sortis et qui sortiront 
encore, mais ipv6 est assurément un *échec* car si c'était aussi bien 
que ça, ipv6 serait partout depuis très longtemps et je ne serais pas en 
train d'écrire dessus.
Je pourrais lancer un autre pavé dans la marre avec IPSEC, on voit bien 
que ce truc-là aussi à réussi ! La preuve: wireguard, openvpn, tous les 
VPN SSL (fortinet par exemple), on se demande pourquoi ces trucs-là sont 
sortis et sont tellement utilisés aujourd'hui !


Ca a quand même un avantage, avec ce foisonnement de protocole, si ipv6 
(ou ipv4) a un gros problème (genre un header bizarre comme on l'a vu 
avec certains attributs BGP, l'histoire n'est pas si vieille), Internet 
fonctionnera encore !

Idem pour les algo de chiffrements et les types et implémentations de VPN.

Jérôme



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

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

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


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



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

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

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


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

La bascule IPv4 => IPv6 a combien d'années de retard ? En 2024 on est à quel 
facteur entre le budget initial et le budget réel (10, 100, 1000 ? Plus ?) ?

L'EPR est bientôt chargé, et côté IPv6 on en est où ? Quel fiasco !!

Jérôme




--
Jérôme Marteaux


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

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

[GROS Jérôme]

Le 12/02/24 19:46, Jérôme Marteaux a écrit :

Le 12/02/2024 à 18:42, David Ponzone a écrit :
L'EPR est bientôt chargé, et côté IPv6 on en est où ? Quel fiasco !!


EPR: €×7, 12 ans de retard, prix du kWh produit = ×2 ET ce n'est pas encore 
fini !
Pour à peine 1600MWe à 100%, juste cette année plus de 3GWc de panneau 
photovoltaïque ont été installé en fr ...
IPv6 est loin d'être à ce niveau d'infamie.


Jérôme






Le 12 févr. 2024 à 18:35, Maximus .  a écrit :

Hello,

Dans notre cas, y’a 1 gros problème pour passer en IPv6
Sur le site on a 2 opérateurs, chacun donne 1 /48.
Comment je fait pour adresser ?

En IPv4, suivant l’accès internet utilisé, ça sera naté par l’IP de l’interface 
utilisé pour soritr.

Mais en IPv6, si j’adresse avec le /48 de l’opérateur 1, comment je fais pour 
sortir par l’opérateur 2 ?
Du nat ?
Oh le nat évoqué en IPv6, de l’urticaire se déclenche chez certains ;)

Cordialement,
Maximus



--
Jérôme Marteaux


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



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

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

[Jérôme Marteaux]

Le 12/02/2024 à 18:42, David Ponzone a écrit :

Ben bien sûr que tu peux faire du NAT quand tu failover sur l’opérateur 2.
C’est ce qu’on appelle une « dégradation » acceptable le temps de l’incident.

Ou sinon, tu fais en sorte que:
-en temps normal, tous les PC obtiennent leur IP en DHCPv6 (ou autre, y a 2 ou 
3 moyens non ? *grin*) du /48 de l’opérateur 1
-en failover, tous les PC ont un renew de leur IP dans le /48 de l’opérateur 2

Si IPv6 sait pas faire ça, c’est que c’est pas fini comme produit.
Tu t’en sors quand même en utilisant des leases très courtes.


Tu pointe les cas bien moisis d'ipv6, en plus d'être incompatible ipv6 
ne copie pas les modes de fonctionnement bien compris et efficaces d'ipv4.
Pour adresser un périphérique il y a n méthodes possibles dont 1 seule 
qui ressemble à ipv4: DHCPv6.
Côté ISP l'adressage des CPE c'est carrément différent, rien n'est 
transposable:

 - le mec qui avait compris ipv4 peut tout ré-apprendre;
 - l'équipementier qui avait implémenté ipv4 peut tout refaire;
 - le SI qui savait gérer ipv4 peut tout refaire.
En général on essaye de valoriser l'acquis pour progresser, il n'y a pas 
eu cette réflexion sur IPv6, ça ne m'étonne pas qu'IPv6 soit un échec.



La seule réussite d'IPv6 c'est dans le mobile et à mon sens pour une 
raison économique:

 - IPv4 a besoin de CGN, ça coûte;
 - IPv6 (grâce aux hébergeu^W GAFAM, merci la population à 99% 
d'eyeball grand public) le coût de DNS64 est bien moins cher que CGN.




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


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


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



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


La bascule IPv4 => IPv6 a combien d'années de retard ? En 2024 on est à 
quel facteur entre le budget initial et le budget réel (10, 100, 1000 ? 
Plus ?) ?


L'EPR est bientôt chargé, et côté IPv6 on en est où ? Quel fiasco !!

Jérôme






Le 12 févr. 2024 à 18:35, Maximus .  a écrit :

Hello,

Dans notre cas, y’a 1 gros problème pour passer en IPv6
Sur le site on a 2 opérateurs, chacun donne 1 /48.
Comment je fait pour adresser ?

En IPv4, suivant l’accès internet utilisé, ça sera naté par l’IP de l’interface 
utilisé pour soritr.

Mais en IPv6, si j’adresse avec le /48 de l’opérateur 1, comment je fais pour 
sortir par l’opérateur 2 ?
Du nat ?
Oh le nat évoqué en IPv6, de l’urticaire se déclenche chez certains ;)

Cordialement,
Maximus



--
Jérôme Marteaux


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

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

[Jérôme Marteaux]

Le 12/02/2024 à 11:12, Pierre Colombier via frnog a écrit :
Je ne sais pas ce que vous en pensez mais ipv6 only, moi je veux bien ! 
C'est quand on veux !


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


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


Et c'est sans doute là la faiblesse d'ipv6, ça n'apporte quasiment rien 
de ce qu'ipv4 sait faire.




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


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

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




L'encapsulation est le métier de base des opérateurs, alors opérer du 
firewall c'est juste un niveau au-dessus, ils pourront survivre à cette 
"évolution".




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




Personne ne peut entendre ça. A mon avis, les 2 seuls éléments qui 
feront "éteindre" ipv4 sont:

 - que plus personne ne veut de transit ipv4 (ce n'est pas prêt d'arriver);
 - que router de l'ipv4 devienne trop cher par rapport à ipv6 et je ne 
vois pas comment ça pourrait techniquement être le cas.



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 ?



--
Jérôme Marteaux


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

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

[GROS Jérôme]

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

Et tjs: https://www.google.com/intl/en/ipv6/statistics.html
Le 10/02/24 16:44, Radu-Adrian Feurdean a écrit :

On Sat, Feb 10, 2024, at 12:51, David Ponzone wrote:

Depuis le temps, je comprends pas que Netflix ait pas encore produit un
docu-série « What killed IPv6 ? » :)


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


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



--
@++
jg.


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

Re: [FRnOG] [TECH] Interface marque blanche téléphonie OVH

[Jérôme Marteaux]

Le 27/01/2024 à 18:05, Stéphane Rivière a écrit :

 >Bonjour Gérald,
Si tu veux amener la marque blanche, les services en clic bouton, 
l'auto-provisionng, la gestion des firmwares, l'intégration mobile, 
l'interface admin, l'interface utilisateur, etc. c'est plusieurs 
années de dev à plusieurs.
J'avais prévu de me limiter aux possibilités courantes proposées par 
l'API d'OVH. Ça aiderait déjà pour le basique, la facturation, etc.
Il manque à OVH une vraie interface de gestion, mais ne faisant que de 
la téléphonie...


+1 Le manager v4 pourri qui reste caché au fond du manager actuel car 
indispensable pour certaines opérations.


De mémoire, OVH avait pris la même infra que Free pour sa VOIP. Une 
filialisation ou un rachat autour de Thalès, il me semble. J'ai oublié 
le nom, pfff... Ça date de 20 ans environ pour Free.


Il s'agit de CIRPACK.

Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Jérôme Berthier via frnog]

Le 22/01/2024 à 18:33, Vinz Jumpertz via frnog a écrit :
je vais poser la question qui fâche: quid de la RGPD? Est-ce vraiment 
nécessaire de collecter toutes ces données, car en cas de pépins ça va 
te retomber dessus. 


Je pense qu'on peut lancer une discussion dédiée. 🙂

J'ai toujours entendu dire que fournir un accès Internet à un visiteur 
nécessite la traçabilité d'un opérateur fournissant le service équivalent.


Vrai ou pas, je trouve ça intéressant de pouvoir se dédouaner de 
certains usages s'ils étaient réalisés depuis une connexion à mon nom.


Pour avoir regarder un peu le RGPD pour d'autres contextes, sans être 
juriste donc sans garantie, je dirai que dans ce cas, la base légale est 
l'obligation légale du fournisseur de l'accès Wifi : 
https://www.cnil.fr/fr/les-bases-legales/obligation-legale


ça justifie la collecte qui doit effectivement être strictement limitée 
au nécessaire, pour la durée utile et être documentée d'un affichage 
l'expliquant y compris les recours possible pour accéder aux données 
récoltées.


En théorie, je crois qu'il faut aussi tenir un registre des traitements 
documentant pourquoi on stocke ces données et qui y a accès.  Bon, dans 
le cas d'un hébergement, des données y en a bien d'autres et tout le 
monde se fout de comment c'est géré... genre les copies de pièce 
d'identité, ça me fait toujours halluciner. Aparté, le service Filigrane 
est sympa pour ça : https://filigrane.beta.gouv.fr/


Pour en revenir au contenu à collecter, j'en suis resté décret 2006-358 
du 24 mars 2006 donc :


« a) Les informations permettant d’identifier l’utilisateur ;
« b) Les données relatives aux équipements terminaux de communication 
utilisés ;
« c) Les caractéristiques techniques ainsi que la date, l’horaire et la 
durée de chaque communication ;
« d) Les données relatives aux services complémentaires demandés ou 
utilisés et leurs fournisseurs ;
« e) Les données permettant d’identifier le ou les destinataires de la 
communication.


donc le triptyque user/MAC/accounting IP habituel...

Depuis je crois que ça a été confirmé par la (magnifique) loi n° 
2021-998 du 30 juillet 2021 relative à la prévention d'actes de 
terrorisme et au renseignement : 
https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI43887545


--
Jérôme Berthier


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

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Jérôme Berthier via frnog]

Le 22/01/2024 à 12:09, Pierre-Henry Muller via frnog a écrit :
Petit retour d'expérience, UI ne permet pas le niveau de détail que tu 
demandes.


Le réseau guest avec voucher ou avec portail, ne demande même pas les 
infos obligatoires que son nom / prénom / email, le portail ne peut 
être modifié sur ce point, seule les couleurs et les CGV peuvent être 
modifiées.


De plus même une dream machine qui fait office de firewall / routeur, 
lorsqu'on active le flux syslog vers un concentrateur, on ne reçoit 
pas le détail du traffic, assignation dhcp et autres infos 
intéressantes mais seulement les logs systèmes de la dream machine et 
des bornes ...



CQFD. Merci




Bilan on a viré notre wifi guest 


Oui mais en 2024, c'est pas une option pour des chambres d'hôtes. 🙂

Je vais voir :

- soit pour intercaler un service de portail captif qui fera le job : 
Alcasar, CloudSpot, Ucopia (mais j'ai pas de canal d'achat) ou tout 
autre suggestion bienvenue


- soit pour ne pas compléter la base UniFi et partir sur autre chose qui 
ferait le job sans sortir des montagnes d'euro.


On me souffle TP-Link Omada (cité aussi mi décembre dans la discussion 
sur une problématique similaire). ça serait un équivalent de la logique 
UniFi mais les traces portail captif / trafic sont-elles correctes et 
exhaustives ?


--
Jérôme Berthier


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

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Jérôme Berthier via frnog]

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

Le 18 janv. 2024 à 22:52, Merwan Zenati  a écrit :

Hello

En effet les bornes sont managées avec un controller, pour du basique, si tu ne 
veux pas mettre de vrai firewall sur place, une cloud key fait amplement 
l’affaire (sinon tu peux héberger une vm Windows/linux avec un controller mais 
prix de l’instance + maintenance + gestion du fw si ip dynamique etc etc etc… 
prise de tête pour la taille)
Ce cloud key est manageable a distance (tu l’adopte dans console.ui.com si je 
dis pas de bêtise) donc c’est top.
Tu couple ça a un 8POE unifi (ou plus selon le besoin et le tour est joué)

Concernant ton wifi guest, unifi, c’est simple ! Tu setup ton lan guest sans « 
network », tu crée ton wifi dans « wifi » tu dis « c’est du guest » boom il 
isole lui même chaque périphérique connecté automatiquement…

Mais sauf erreur de ma part (j’ai éliminé tous les routeurs UI de la liste du 
possible il y a un moment), dans cette conf, tu n’as pas les logs des guests 
sur 12 mois.
C’est un produit US, donc ils connaissent pas trop nos petites contraintes UE 
(qui sont, il faut le dire, ubuesques).


Merci David pour cette remarque !

En relisant quelques docs et posts sur le forum UniFi, j'ai 
effectivement un gros doute aussi.


L'idée du déploiement est évidemment d'avoir la traçabilité entre le 
client (voucher hotspot) et son usage (terminal / trafic IP).


Il me faut donc la traçabilité :

- des connexions hotspot en pouvant faire le lien entre le 
client/voucher et son terminal (idéalement sur un an).


- du trafic en lien avec le terminal (idéalement le voucher donc le client)

Pour croiser tout ça, j'ai donc besoin des logs : sessions portail 
(client/voucher <-> MAC), MAC <-> DHCP, accounting IP (src / dst / 
ports...), translations NAT.


Je pensais que les gateways UniFi et la fonction Hotspot gérée dans 
Network Server permettaient d'avoir ça mais c'est franchement pas clair.


Je crois même comprendre le contraire en lisant le forum Community UniFi.

--
Jérôme Berthier

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

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Jérôme Berthier via frnog]

Le 14/01/2024 à 11:22, Paul Rolland (ポール・ロラン) a écrit :

5) y a des gateway qui intègrent UniFi Console qui permet d'instancier
UniFi Network Server ou de joindre le cloud UI

Oui. Ca peut d'ailleurs te permettre de recuperer une fonction "routeur"
(et donc la partie DHCP). Dans ta liste de materiel, tu as liste un switch
et les AP, mais pas de routeur... je suppose que tu prends celui qui vient
avec l'acces Internet ?



oui j'ai pas parlé de la partie routeur car par défaut, le gestionnaire 
pensait utiliser sa livebox.


Je lui ai exposé les limites de ça. Je pense qu'il a capté pourquoi ce 
serait utile de cloisonner un peu les usages.





IMHO, il te faut, pour etre bien:
  - un switch PoE, qui te fera l'alim de tes bornes. Et si il est Unifi, tu
le geres avec le reste dans ta console, genre le Lite 16PoE, qui te fait
16 ports, dont 8 avec PoE+, ce qui couvre tes 5 APs
  - une console on-site, qui te fera la brique "controleur", le DHCP, ...


OK grâce à vos différents retours, on a levé mes doutes sur l’enrôlement 
des bornes. Y a pas vraiment de contrôleur, c'est plutôt un manager. 
Chose plutôt pas mal, on peut remonter cette console locale dans le 
cloud UI, ce qui donne une vue distante de l'installation. ;)


On est rendu entre 6 et 8 APs selon les positionnements finaux 
(contraintes de pose). Elles sont POE standard, pas besoin de plus. Par 
contre, me faut un switch qui peut gérer quelques vlans.


On va donc effectivement ajouter une passerelle intermédiaire derrière 
sa box.


Au delà de la segmentation et adressage clients, je suppose que ça 
assure aussi la traçabilité des sessions IP ? et que ça remonte les logs 
dans la console ?


Pour la partie hotspot, c'est simpliste mais ça fait le job. Si en plus 
la passerelle fait l'accounting IP, ce sera parfait en terme de traçabilité.


Merci à tous pour les différents retours

--
Jérôme Berthier

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

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Jérôme Berthier via frnog]

Le 13/01/2024 à 16:32, Jérôme Berthier via frnog a écrit :
J'ai démarré une instance UniFi Network Server pour voir à quoi ça 
ressemble.


Je vois qu'on peut demander une fonction portail captif. Par contre, 
après l'avoir activé, je ne vois aucun menu de gestion des comptes 
guest. Ce n'est pas proposé ?? 


OK je pense avoir trouvé pour ce point.

Après avoir personnalisé le portail en activant l'authentification par 
voucher, un menu apparaît pour gérer les comptes. C'est très rudimentaire.


--
Jérôme Berthier


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

[FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Jérôme Berthier via frnog]

Salut la liste,

Je file un coup de main pour une installation Wifi d'un petit 
établissement qui a des chambres d'hôtes.


C'est un rachat. Le proprio précédent a laissé du matos à installer : 
cinq APs UniFi UAP-AC-LITE et un switch POE Netgear non manageable 
(champagne !).


Je ne connais pas les solutions Unifi. Après un peu de lecture, si je 
pige bien :


1) ce sont des AP légères donc faut un contrôleur à part (même s'il 
semblerait possible de les paramétrer unitairement)


2) il faut donc l'application UniFi Network Server

4) soit on héberge ce service, soit on le consomme chez UI

5) y a des gateway qui intègrent UniFi Console qui permet d'instancier 
UniFi Network Server ou de joindre le cloud UI



Comme le tenancier n'est pas vraiment informaticien, je vais plutôt lui 
conseiller des éléments packagés qui "juste marchent".


Du coup, en regardant les boîtiers type gateway, pour pas trop cher, 
j'ai l'impression qu'il y aurait :


- le boîtier CloudKey+ UCK-G2-PLUS (console OnPrem)

- le boîtier UniFi Express UX (console Cloud UI) mais limité à quatre 
devices pilotés


- le boîtier Dream Router UDR (40W) (console Cloud UI)

Est-ce bien ça ?


J'ai démarré une instance UniFi Network Server pour voir à quoi ça 
ressemble.


Je vois qu'on peut demander une fonction portail captif. Par contre, 
après l'avoir activé, je ne vois aucun menu de gestion des comptes 
guest. Ce n'est pas proposé ??



Je vais aussi tenter de lui faire changer son parpaing POE pour avoir 
une gestion de vlan (histoire de séparer l'adressage des APs, le guest 
et surement un SSID privé). Une idée du modèle de switch UniFi (10 ports 
utiles) ?



Côté docs, j'ai du mal à trouver des réponses à mes questions...

Si une bonne âme veut bien m'aiguiller. 🙂


Merci d'avance

Bon week-end

--
Jérôme Berthier


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

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

[Jérôme Marteaux]

Le 05/01/2024 à 20:18, N R a écrit :

Bonsoir monde,
C'est vrai qu'avec l'exemple de Lapsus$ qui bombardait l'utilisateur⋅ice de
notifications MFA jusqu'à ce qu'il ou elle cède et leur succès à infiltrer
Micromou, Okta ou Nvidia, ça valide l'effet "sécurité qui rajoute des
trous" du MFA.

Je plussoie au constat que c'est devenu délirant, peut-être un vrai effet
NoCode, il n'y a pas besoin de compétences particulière pour compromettre
des infrastructures critiques, voir aussi l'exemple InfraGard infiltrée par
USDoD.

[2 cents Vendredi]
À toujours proposer des solutions techniques à des problèmes foncièrement
humains, on fragilise l'infrastructure et l'humanité d'un coup.
Globalement j'ai la sensation aussi que la sécurité c'est toujours pour se
rassurer ou un problème pour les autres.
[\0/]

Après, c'est sûr que mettre du MFA et un mot de passe un poil plus
résistant à du bruteforce (post-quantum everything toussah) sur des
interfaces critiques et exposées ça protège du tout-venant.
L'OTP c'est bien aussi quand c'est bien fait, ou les jetons physiques genre
Yubikey, Onlykey...

Nicolas 'Kholah' Randrianarisoa

Le ven. 5 janv. 2024 à 12:05, Stephane Bortzmeyer  a
écrit :


On Thu, Jan 04, 2024 at 09:39:15AM +0100,
  David Ponzone  wrote
  a message of 21 lines which said:


Allez, activation du MFA partout sur RIPE (et les autres RIRs),

histoire

que au moins on remette le besoin d'un acces a un device physique

(router

ou token) pour continuer a casser notre bel outil.


Pas forcément, si tu caches mal ton emergency code :)


Ou si on se laisse prendre à de l'ingéniérie sociale. Le MFA est
évidemment impératif pour les comptes au RIPE mais ce n'est pas une
solution miracle.

La leçon que j'en tirerai est plutôt « toute technique de sécurité
peut être détournée pour créer une attaque par déni de service ».



Ou alors faut-il passer à l'étape d'après et faire un réseau dédié au 
RIPE comme celui du GIE EGP (portabilité des mobiles) ou de l'APNF 
(portabilité fixe) ou de SWIFT (bancaire).
Les machines qui gèrent ces échanges entre opérateurs sont uniquement 
accessible via un VPN.


C'est beaucoup moins souple qu'Internet, mais ça ajoute une couche de 
sécurité (ça n'empêche pas ceux qui mettent en place du NAT/reverse 
proxy pour y simplifier l'accès).
L'obscurantisme n'est pas idéal non plus, mais pour quelque chose 
d'aussi sensible que les objets routes et l'utilisation qui en est 
faite, de cacher ça derrière un VPN serait un moindre mal.
(les cotisations du RIPE vont en prendre un sacré coup pour créer et 
faire le support des 22 000 VPN à mettre en place).



Jérôme

--
Jérôme Marteaux


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

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

[Jérôme Marteaux]

Le 05/01/2024 à 11:39, Xavier Beaudouin via frnog a écrit :

Hello,


Il y a bien le contact jour/nuit (enfin, HP/HC) sur les électroniques
blanc .. mais il est déjà utilisé quoi :p


Voilà...
Sur les anciens compteurs électronique il y avais un second contact
utilisé... pour les EJP / Tempo Rouge.

Sauf que les gens super bien payés ont décidé "oh ça sert à rien
alors on vas supprimer le contact pour gagner 1€ (larrrge)" sur la
fabrication de ce compteur.

Bien vu ! (Alors QUE JUSTEMENT, ce contact aurait pu être utilisé).
  

À un moment, il faudrait quand même qu'Enedis se mette à produire des
API qui marchent ... Patcher les infos transmises par la TIC, ça suppose
qu'elle soit exploitée chez l'abonné et que les appareils qui
l'exploitent soient patchables ...


Qui marchent (pour l'instant, ca a l'air chez moi sur HomeAssistant) ET
qui n'aient pas besoin d'un yet another fscking compte de merde pour.
  

J'met plutôt 10 balles sur des smart-trucs-tuya-cloud-based chargés de
réguler (un radiateur, une PAC, ...) et qui feront du wifi avec la
bidulebox plutôt que sur une généralisation de domotiques lourdes
branchés aux TIC des compteurs (qui sont bien souvent en dehors de la
maison avec un fourreau plein comme un oeuf ou bien écrasé depuis 15 ans)


Bah ça c'est encore une victoire d'Enedis qui ne voulais pas se faire chier
a sonner pour relever le compteur.



Toujours pareil, il faut diminuer les budgets du service public, donc 
faire des économies, donc supprimer de la masse salariale. Mais un point 
pour toi, il n'y a pas énormément de valeur ajoutée à relever des compteurs.



Après j'ai entendu dire que tu peux faire rappatrier ton compteur chez
toi depuis que le Linky est là.


Mais ça suppose un brin de volonté et un peu d'infra fonctionnelle ...
Genre "créez votre compte Enedis, associez votre compteur, activez l'API
de délestage, branchez vos grille-pain sur un smart-truc de la liste
suivante et gagnez 10 balles par mois"


Pour 10€ par mois OSEF... c'est 1% de ma facture. Sachant qu'il n'y a
que les passionnés de domotique qui vont le faire donc en gros
personne.

Après quand on voit ce qu'il font au pays bas avec les API pour les
tarifs de l'électricité alors que nous pourrions en tant que particulier
délester heure par heure si on avais des putain d'API...

Exemple :
https://www.victronenergy.com/live/drafts:dynamic_ess

Mais bon... voilà on n'est pas capable de faire ce qu'il faut


Cela suppose que tu paye un prix de l'électricité variable.

Question personnelle: est-ce que le crédit de ta maison est à taux 
variable ?


Je ne suis pas certains que multiplier les sources d'énergie et les 
équipements pour les utiliser (chaudières gaz, fioul, PAC, batteries, 
panneau solaire, éolienne à la maison, hydro dans son jardin ...) et de 
moduler ensuite en fonction de la disponibilité et des coûts soient la 
meilleure solution.


Je pense qu'un gros gap serait:
- de piloter le chargement des voitures électrique la nuit: on pourrait 
avoir un ou plusieurs réacteurs nucléaire qui fonctionnerait ainsi en 
base (sans avoir à moduler sa puissance, on augmenterait alors son 
facteur de charge tout en diminuant sa maintenance);
- lorsqu'on a des moments difficile à passer en terme de production, ces 
voitures électrique pourraient renvoyer leur énergie stockée au réseau.


D'ailleurs, pourquoi on n'étendrait pas ce concept à l'eau ? Des villes 
commencent à mettre en place un tarif différent entre l'hiver et l'été. 
Pourquoi ne pas constituer des fournisseurs alternatifs, c'est un monopole !
Je suis sûr qu'apparaîtrait des vendeurs d'eau certifiés bio et 
équitable ! :)



Jérôme

--
Jérôme Marteaux


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

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

[Jérôme Marteaux]

Le 05/01/2024 à 09:40, Spyou a écrit :


Le 04/01/2024 à 22:46, Julien Escario a écrit :


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

"


Il y a bien le contact jour/nuit (enfin, HP/HC) sur les électroniques 
blanc .. mais il est déjà utilisé quoi :p



À un moment, il faudrait quand même qu'Enedis se mette à produire des 
API qui marchent ... Patcher les infos transmises par la TIC, ça suppose 
qu'elle soit exploitée chez l'abonné et que les appareils qui 
l'exploitent soient patchables ...


J'met plutôt 10 balles sur des smart-trucs-tuya-cloud-based chargés de 
réguler (un radiateur, une PAC, ...) et qui feront du wifi avec la 
bidulebox plutôt que sur une généralisation de domotiques lourdes 
branchés aux TIC des compteurs (qui sont bien souvent en dehors de la 
maison avec un fourreau plein comme un oeuf ou bien écrasé depuis 15 ans)


Mais ça suppose un brin de volonté et un peu d'infra fonctionnelle ... 
Genre "créez votre compte Enedis, associez votre compteur, activez l'API 
de délestage, branchez vos grille-pain sur un smart-truc de la liste 
suivante et gagnez 10 balles par mois"




Ca existe déjà, le truc qui baisse la température des radiateurs comme 
par exemple https://www.voltalis.com/


Dans les faits, RTE rémunère des sociétés qui peuvent & veulent effacer 
leur consommation: 
https://www.services-rte.com/fr/decouvrez-nos-offres-de-services/beneficiez-d-un-soutien-aux-effacements.html


ou encore https://www.cre.fr/Electricite/Reseaux-d-electricite/Effacements

Voltatis a un business modèle différent, en offrant le service de 
thermostat connecté, Voltatis se rémunère sur les contrats d'effacement 
de RTE. Malin.


Par exemple ce soir à 19h RTE va activer 3 MW d'effacement:
https://www.services-rte.com/fr/visualisez-les-donnees-publiees-par-rte/effacements-de-consommation-nebef.html

Tout est en place (techniquement, économiquement) pour adapter la 
consommation à la production, mais je pense que les problèmes sont:

- de faire connaître au grand public & tertiaire que ça existe;
- de construire plusieurs scénarios de pilotage de la consommation:
  - en fonction de l'environnement et de toutes ces contraintes 
(télétravail, retraité, mercredi à la maison, vacances)
  - faisabilité technique: type de chauffage, chauffe eau ... bref 
comment rendre l'installation modulable;

  - pouvoir évaluer l'impact sur le mode de vie;
  - chiffrer les investissements;
  - chiffrer le retour sur investissement;
=> et comme chaque habitation & tertiaire sont uniques, ça va prendre du 
temps, énormément de temps.


Comme les ISP ont pris le virage du mobile en devenant MVNO, je suggère 
aux ISP de prendre le virage du fournisseur d'énergie comme nouveau 
relai de croissance, je pense qu'il y a des choses à faire.
Aucun ISP ne s'est positionné sur le marché, mais c'est sûr que ce 
marché n'en est qu'à ces balbutiements.


Jérôme

--
Jérôme Marteaux


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

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

[Jérôme Marteaux]

Le 04/01/2024 à 18:38, Toussaint OTTAVI a écrit :


Le 04/01/2024 à 18:11, Jérôme Marteaux a écrit :
En fait c'est une souscription *volontaire*, donc il se peut que tu 
sois volontaire et ainsi affecté par la baisse de puissance mais que 
ton voisin ne soit pas volontaire et donc son frigo continuera de 
fonctionner.


Bon, c'est déjà çà ;-)

Il n'en demeure pas moins qu'il serait pertinent de connaître les 
détails de fonctionnement de ce "délestage par réduction de puissance". 
Car le jour où çà se généralisera, nous aurons besoin de savoir comment 
çà fonctionne, afin de prévoir nos systèmes aval en conséquence.


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




Je pense que les gestionnaires et le politique se tâtent pour la 
politique à mener quand aux futures délestages, d'où cette expérience.


Où se trouve le seuil d'acceptabilité ? Avec quelles contraintes ? Quels 
modes opératoires (délestage tournant, rémunéré ...) ? Et notamment 
comment communiquer dessus.


D'ici là que le politique se dise qu'il fasse monétiser tout ça pour
rendre l'opération plus qu'attrayante et ainsi mettre le turbo sur 
l'acceptabilité de l'opération, il n'y a qu'un pas (avant l'abîme) et 
une future usine à gaz ! Qui se souvient des certificats d'électricité 
verte et des garanties d'origines ? :)


Jérôme

--
Jérôme Marteaux



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

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

[Jérôme Marteaux]

Le 04/01/2024 à 16:37, Julien Escario a écrit :

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


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


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

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

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


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


En fait c'est une souscription *volontaire*, donc il se peut que tu sois 
volontaire et ainsi affecté par la baisse de puissance mais que ton 
voisin ne soit pas volontaire et donc son frigo continuera de 
fonctionner. Donc pas de risque d'être impacté sans l'avoir voulu.


Le décret en question est très clair sur les modalités du test:
https://www.legifrance.gouv.fr/jorf/id/JORFTEXT48729906

Y-compris sur le délai de prévenance et sur les horaires et durée des tests.


Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] Routeur L3 low-Cost 10 Gbps.

[Jérôme Marteaux]

Le 02/01/2024 à 19:14, Paul Rolland (ポール・ロラン) a écrit :

Bonjour.

On Tue, 2 Jan 2024 19:07:25 +0100
David Ponzone  wrote:


Ouais bien joué, c’est ça, y a un bus 4x10 entre le switch-chip et le CPU:
https://i.mt.lv/cdn/product_files/CCR2116-12G-4S_230247.png
<https://i.mt.lv/cdn/product_files/CCR2116-12G-4S_230247.png>


Bien vu, j'avais vu ca dans la spec du produit, mais sans pousser le
raisonnement.
  

Moralité: pour utiliser les 4 ports 10G presque à fond, ça doit le faire,
mais faut pas trop jouer avec les ports 1G en même temps.


Du coup, ca pourrait etre un bon produit pour Patrick M si il peut se
contenter de 4x10G, et mettre des bouchons dans les ports 1G pour ne pas
etre tente de faire qq chose avec ;)

Reste donc a regler le probleme de la syntaxe infââÂÂââme de mikrotik ;)


On comprend pourquoi tous les équipementiers récents ont copiés la CLI 
Cisco, c'est pas par hasard.
Mais le côté très sympathique de Mikrotik c'est que contrairement à 
Cisco, l'interface web (et même le client lourd) est utilisable et bien 
fait. En plus c'est bien pratique car il n'est pas nécessaire d'être 
expert pour y faire des choses.
Dommage qu'il n'y a pas un document qui fait un diff entre une config 
classique cisco et une config mikrotik, ça permettrait de mettre le pied 
à l'étrier, de même que trouver où sont les logs, les stats des 
interfaces, comment on sauvegarde la config, comment on upgrade ...

sans avoir à lire toute la doc.

Un autre bon point pour Mikrotik c'est la doc qui est concise et claire.
Il manque juste un bugtracker car les forums ça va bien 2 minutes ...

Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] Routeur L3 low-Cost 10 Gbps.

[Jérôme Marteaux]

En fait, c'est une bonne plateforme ! Les meilleures perf sont obtenues 
avec des paquet de 64 et 512 octets !


En effet, si on lit la ligne Routing 25 simple queues en kpps:
1518: 3212.2
512:  *6322.6*
64:   *6300.9*

J'en conclus que la plateforme est capable de router 6300 kpps.
Mais pourquoi avec des paquets de 1518 la plateforme n'arrive pas à 
faire ces 6300 kpps ?

(idem pour les 25 ip filter rules mais avec 3900 kpps)

Si l'ont a des paquets de 1518 il est préférable d'être en fast path ou 
L3HW pour avoir les meilleures perf.


Y aurait-t'il un goulet d'étranglement sur un bus interne limitant les 
perfs à 40 Gbps quelque soit les pps en jeu ?


Jérôme

Le 02/01/2024 à 18:19, David Ponzone a écrit :

Jérôme,

On est bien d’accord mais pourquoi ça marche qu’avec les paquets de 1518 ? :)


Le 2 janv. 2024 à 17:50, Jérôme Marteaux  a écrit :

C'est du hardware assisted routing.

Ca fonctionne comme ça:
- lorsqu'un paquet match des données en cache (vlan, ip destination, port 
output, mac ...) alors le network processor a toutes les infos pour router le 
paquet;
- sinon il y a un cache miss et le paquet remonte jusqu'au CPU pour être géré 
en soft.

Le premier paquet d'un flux remonte au CPU qui le traite en soft, puis 
programme le network processor pour gérer les futurs paquets de ce flux.




--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] Routeur L3 low-Cost 10 Gbps.

[Jérôme Marteaux]

Le 02/01/2024 à 16:34, Paul Rolland (ポール・ロラン) a écrit :

Bonjour,

Bonne annee a tous,


On Tue, 2 Jan 2024 13:41:54 + (UTC)
Xavier Beaudouin via frnog  wrote:


Salut Patrick et bonne année :)


Avez-vous des conseils d'achat pour un routeur low-cost supportant du
routage à 10 Gbps ?

J'ai repéré de mon coté le Zyxel XS1930-10, mais sa réelle capacité
reste à valider.


#define routage à 10Gbps... ? Parce y a aussi les Mikrotik même si la
syntaxe de routeros peux donner mal à la tête... mais on s'y fait :D


Un familier du produit pour expliquer les chiffres de perf de
https://mikrotik.com/product/ccr2116_12g_4splus#fndtn-testresults
et en particulier :

Routing none (fast path)3212.2  39009.0 9125.3  37377.2 28095.6 15284.0
Routing 25 simple queues3212.2  39009.0 6322.6  25897.4 6300.9  3427.7
Routing 25 ip filter rules  3212.2  39009.0 3927.9  16088.7 3901.5  2122.4

J'ai du mal a comprendre pkoi les paquets de 512 et 64 octets sont bcp plus
impactes par la mise en place des simple queues ou des filter rules, alors
que les perfs sur les 1518 bytes sont inchangees...



C'est du hardware assisted routing.

Ca fonctionne comme ça:
 - lorsqu'un paquet match des données en cache (vlan, ip destination, 
port output, mac ...) alors le network processor a toutes les infos pour 
router le paquet;
 - sinon il y a un cache miss et le paquet remonte jusqu'au CPU pour 
être géré en soft.


Le premier paquet d'un flux remonte au CPU qui le traite en soft, puis 
programme le network processor pour gérer les futurs paquets de ce flux.


C'est une façon d'avoir un network processor petit et donc pas cher tout 
en ayant des fonctionnalités avancées.

Foundry Networks faisait ça il y a bien longtemps avec ces BigIron.

Certaines box wifi genre TP LINK ou autres qui écrivent "hardware 
assisted NAT" où le premier paquet est traité en soft, l'entrée est 
ensuite descendue en hard et les paquets qui suivent sont donc traité en 
hard ce qui permet d'atteindre plus d'un gigabits en NAT avec un 
processeur anémique (un bon ARM pas cher, consommant peu d'énergie et 
qui chauffe peu). Par rapport à une solution 100% soft ou 100% hardware, 
les limites de ce hardware assisted sont:
 - le nombre de flux simultané, car le nombre d'entrée dans le 
processeur réseau est fini et limité;

 - le nombre de nouvelles connexions /s limitée par la puissance du CPU;

Sur ce même Mikrotik tu n'as pas recopiée la dernière ligne:
mode: routing
configuration: none (L3HW)
qui donne *73* Mpps sur des paquets de 64 octets.

Les fortinet et autres firewall fonctionnent de la même façon. Les SBC 
hardware fonctionnent aussi comme ça, la pile SIP tourne sur un CPU x86 
et les flux transitent en hard (avec ou sans transcoding).


Pour garder des grosses perfs quelque soit les fonctionnalités activées 
il n'y a que les ASIC qui permettent de le faire en 100% hard et ce 
n'est pas la même gamme de prix.


Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] L2 stretché sur des 9300

[Jérôme Quintard]

Oui les vPC ne sont pas supportés.

Jérôme

> Le 11 déc. 2023 à 13:53, Ambroise via frnog  a écrit :
>
> Je pense que Jérôme parle de Catalyse 9300 qui, si je lis bien, ne 
> supportent pas le vPC (seuls les Nexus le supportent il me semble)
>
> Ambroise
>
> Le 11 décembre 2023 12:45:37 UTC, David Ponzone  a 
> écrit :
>> Les 9300 supportent vPC non ?
>>
>> Ca va pas à ton use-case ?
>>
>> David
>>
>>>> Le 9 déc. 2023 à 10:21, Jérôme Quintard  a écrit :
>>>
>>> Bonjour à tous,
>>>
>>> On doit stretcher impérativement un L2 entre deux 9300 qui sont dans des 
>>> salles différentes, connectés par un jeu de fibres + un secours radio. Les 
>>> 9300 ne supportent pas les stack virtuels, uniquement du physique.
>>>
>>> On a donc pas quarante choix :
>>>
>>> - Multiplexer les fibres
>>> - Faire du HSRP
>>> - Utiliser un tunnel VXLAN
>>>
>>> Toutes ont des avantages et des inconvénients.
>>>
>>> C’est entre autre pour un PCA sur un hypeconvergeur de type ROBO moins on 
>>> ajoutera de traitement mieux ce sera.
>>>
>>> Vous feriez quoi ?
>>>
>>> Jérôme
>>>
>>>
>>>
>>>
>>> ---
>>> 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/

[FRnOG] [TECH] L2 stretché sur des 9300

[Jérôme Quintard]

Bonjour à tous,

On doit stretcher impérativement un L2 entre deux 9300 qui sont dans des salles 
différentes, connectés par un jeu de fibres + un secours radio. Les 9300 ne 
supportent pas les stack virtuels, uniquement du physique. 

On a donc pas quarante choix :

- Multiplexer les fibres
- Faire du HSRP
- Utiliser un tunnel VXLAN

Toutes ont des avantages et des inconvénients.

C’est entre autre pour un PCA sur un hypeconvergeur de type ROBO moins on 
ajoutera de traitement mieux ce sera. 

Vous feriez quoi ?

Jérôme 




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

Re: [FRnOG] [ALERT] Backbone COVAGE/AI en vrac dans le Grand Ouest, encore, encore et encore ...

[Jérôme Marteaux]

Le 07/12/2023 à 17:58, Toussaint OTTAVI a écrit :


Le 07/12/2023 à 11:26, David Ponzone a écrit :

Y avait-il dans le cahier des charges du délégant la moindre allusion à
la redondance du raccordement du RIP au backbone du délégataire ?


M'ouais... C'est un peu comme si, lorsqu'on achète une voiture, on 
devait se demander si elle freine bien devant *et* derrière ;-)


Aujourd'hui, pour remporter un appel d'offres, il faut être moins cher. 
Et pour être moins cher, il n'y a pas de secret, il faut faire de la 
m***, pardon, il faut rogner partout où on peut ! Tout le réseau public 
Français, de la "fibre" à la 4G "New Deal" est construit suivant ce 
postulat. Donc, exit la résilience, la robustesse, la tolérance aux 
pannes ! Tant pis pour les réseaux maillés, qu'on est censés enseigner 
en première année d'école télécom, et tant pis pour Arpanet ! Le réseau 
télécom Français, c'est effectivement de l'Internet jusqu'à Paris, ou 
exceptionnellement jusqu'à quelques grandes métropoles où certains très 
gros ont des infras. Tout le reste, c'est un réseau pyramidal fermé où 
chacun fait un peu ce qu'il veut dans la plus totale opacité. Ce qui est 
d'autant plus facile que personne n'y comprend grand chose, et donc que 
pas grand monde ne semble savoir poser les bonnes contraintes dans ses 
cahiers des charges. "Internet" et "le Cloud", c'est bien connu, çà 
marche tout seul, et on n'a plus besoin de se soucier de 
l'infrastructure :-D


Le résultat est qu'assez régulièrement, pour des causes aussi diverses 
que variées (sabotages, tempêtes, doubles pannes, défaut d'énergie, 
niveau de compétences...) çà pète à grande échelle. Et encore, à part la 
météo qui, ces dernières années, nous ménage de moins en moins, nous ne 
sommes pas en guerre contre une puissance étrangère, ni même n'avons été 
victimes d'actes de terrorisme sérieux visant les infrastructures 
numériques. Jusqu'à quand ?


Et on feint d'être surpris ? Que de telles coupures produisent au beau 
milieu de la montagne sur une île perdue, à défaut de l'accepter, je 
pourrais encore le comprendre. Il y a une seule fibre, en aérien, sur 
20km, au milieu du maquis, et un seul câble EDF... Mais que cela se 
produise dans des grandes régions de métropole est quelque chose qui 
m'échappe totalement. Si l'on fait le cumul de tous les opérateurs, les 
infrastructures physiques (les fibres) y sont, et apparemment, en grand 
nombre ! On en revient, encore et toujours, à la notion de 
décentralisation du réseau, qui n'est absolument pas mise en oeuvre en 
France. Et on se demande bien pourquoi ! Tout remonte sur Paris par des 
moyens divers et variés.


Personnellement, je ne peux pas m'empêcher d'imaginer des 
plaques/POP/GIX à Lille, Rouen, Rennes, Nantes, Bordeaux, Toulouse, 
Perpignan, Marseille, Nice, Lyon, Strasbourg (sans oublier Ajaccio et 
Bastia), tout çà en full-BGP, avec tous les liens de tous les opérateurs 
existants. Le pire, c'est que tout cela est possible quasiment sans 
faire une seule tranchée !


Le corollaire est que, contrairement à une voiture, si on achète un lien 
télécom aujourd'hui, on n'est absolument pas certain qu'il va freiner 
quand on appuiera sur la pédale. Le service public, c'est bel et bien 
terminé ! Si l'on veut avoir un minimum de garanties, il faut acheter et 
construire soi-même sa résilience : des liens différents chez plusieurs 
opérateurs différents, avec des cheminements différents (quand on les 
connaît). Avec un seul lien chez un seul opérateur, peu importe la GTR 
ou les SLA, un jour ou l'autre, çà explosera. Et malheureusement, les 
exemples sont nfréquents ici où même deux liens différents chez deux 
opérateurs différents ne suffisent pas.


La semaine dernière, on fustigeait Orange pour avoir remis au catalogue 
des offres satellite. A la base, je pense que c'était surtout pour 
essayer de s'affranchir en douce de l'obligation de fourniture du 
service universel en FTTH dans les endroits les plus reculés du pays. 
Ceci étant, moi, je suis bien content d'avoir les satellites, car au 
niveau de la résilience, çà fait le job que ne font plus les opérateurs 
"filaires" !


En plus du mobile qui rentre dans la dénomination du "très haut débit".
(image en bas à droite sur 
https://www.gouvernement.fr/action/le-plan-france-tres-haut-debit)


En fait, tu peux prendre ça sous l'angle Européen à savoir la 
sacro-sainte concurrence: le service étant mauvais, il y a donc une 
place pour un autre opérateur pour proposer un meilleur service.


A moins que la concurrence ne soit faussée pour cause de territoire 
économiquement non rentable et que la solution de la DSP 
d'infrastructure n'est sans doute pas la bonne solution.


C'est aussi l'occasion pour ces opérateurs d'être plus transparent sur 
leurs moyens et leurs infrastructures internes plutôt que de nous vanter 
le seul nombre de prise ouverte.


Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [BIZ] Fournisseur connexions FTTx

[Jérôme Marteaux]

Le 01/12/2023 à 09:31, Olivier Varenne a écrit :

Bonjour

Actuellement chez Alphalink (entre autres) pour la data (mobiles, FTTx, xDSL), 
nous rencontrons de plus en plus de soucis sur les connexions.
Perte de liens sans explication lors de la récupération du service
Problèmes lors des déploiements de FO (bon, ça... )
Support qui devient de plus en plus inefficace...

Quelqu'un a-t-il un concurrent/son propre service à me proposer qui soit :

   *   Humain
   *   Qui soit joignable, surtout quand ça merdouille
   *   Qui soit pas cher (et oui... on a les clients qu'on a ! et tous 
recherchent un prix  malheureusement)

On recherche pour les FTTX, un peu de xDSL parfois quand pas elligible, et 
pourquoi pas trunk SIP si les couts sont intéressants et si fonctionnalités 
correspondant à nos besoins.




Déjà tu pourras supprimer le coût de la / des VISP et du transit ce qui 
n'est pas rien !


--
Jérôme Marteaux



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

Re: [FRnOG] [BIZ] Re: Orange Offre

[Jérôme Marteaux]

Je n'y connais rien en satellite, quelles sont les différentes techno ? 
(en gros)


Et quelle est la typologie des opérateurs, j'ai l'impression qu'il y a 
une myriade de revendeur, mais peu d'acteurs qui vendent en direct, 
c'est un positionnement voulu ou bien une contrainte de marché ?


Jérôme

Le 27/11/2023 à 15:29, Nang Bat a écrit :

Konnect c'est plus une "marque" qu'un satellite, car derrière konnect
& neosat il y a deux satellites, un premier lancé en 2020 (Renommé
Konnect, anciennement BB4A) et un second majoritairement financé par
de l'argent public (Konnect VHTS, lancé en 2022). Les deux satellites
restent des geo legacy (charge utile sur mesure, peu flexible,
couverture gravée dans le marbre à la construction). Mais sinon dans
l'absolu un Konnect/Konnect-VHTS c'est exactement le meme type de
conception/architecture qu'un Thaicom 4/IPStar d'il y a presque 20 ans
avec un peu plus de capacité RF à bord mais rien de nouveau ni unique
en soit. Typiquement on retrouve exactement le même genre de gros geo
produit par SSL/Maxar pour Hughes
https://www.hughes.com/sites/hughes.com/files/2023-06/JUPITER-3-Fact-Sheet.pdf,
avec des performances légèrement supérieur ceci-dit. Après l'histoire
récente montre que dans une certaine mesure faire du legacy peut être
plus safe (cf. Viasat 3 qui a eu un problème de déploiement de
réflecteur et les soucis d'alim des premiers o3b mPower).

Plus que de l'amélioration c'est de la ressource supplémentaire en
fréquence et la possibilité de déployer un nouveau segment sol (sans
impacter les anciens clients encore actifs) qui améliore
considérablement les performances par rapport a du tooway/ka-sat.
Hormis la dispo en fréquence, le segment sol fait la majorité des
performances en geo en fait, et les segments sols c'est pas
interopérable d'un fournisseur à l'autre, donc compliquer de migrer
une fois un parc de clients mis en prod, et donc un nouveau satellite
sur une nouvelle position c'est l'occasion de repartir sur un truc
tout neuf.

Et sinon oui quelques gros telcos qui avaient un peu de satellites
dans leur portfolios sont devenus revendeurs officiels de starlink
(https://support.starlink.com/?topic=9b7746f8-e2ee-0fd4-7ffb-3bbe0ab35cbc),
après c'est compréhensible, pour de l'accès LEO y'a juste pas de
concurrence pour le moment, et même la concurrence à venir on est pas
au top niveau crédibilité, à part peut-être o3b mpower, mais bon avec
les premiers satellites qui fonctionne mal c'est pas gagné.

Le lun. 27 nov. 2023 à 14:49, Toussaint OTTAVI  a écrit :



Le 22/11/2023 à 16:27, Nang Bat a écrit :

Disons qu'Orange a investi tôt dans ce satellite, icône des gros satellites
géostationnaires dont la pertinence était déjà discutable au moment de la
signature du contrat avec Thales


Le satellite géostationnaire Konnect est en l'air depuis 2021, me semble
t-il. Lors de sa sortie, il a constitué un "upgrade" technologique
important, notamment par rapport aux anciennes solutions Tooway de 2012
(qui ont refait parler d'elles lors de l'invasion de l'Ukraine). Les
offres commerciales Konnect/Neosat sont déjà commercialisées depuis un
moment. Ce sont des trucs assez robustes, qui fonctionnent. Sur une
montagne exposée au vent salin et à la neige, je mets plus volontiers çà
que le gadget Starlink motorisé :-)

Si je comprends bien, Orange se contente aujourd'hui de revendre la
solution technique d'une de ses filiales sous son nom propre. C'est
juste un artifice marketing :-) Probablement destiné à toucher une cible
plus importante, en raison de la plus forte visibilité de la marque
Orange. Cà existe déjà depuis deux décennies, par exemple pour les noms
de domaine fournis avec les offres "Orange Pro", dont la prestation
technique était réalisée par la filiale "Le Relais Internet",
aujourd'hui "NordNet". Je n'y vois rien de choquant.


Après OBS est maintenant revendeur officiel de Starlink.


Ah, tiens, j'ai raté çà :-) C'est vrai que, chez OBS, il n'y a pas de
catalogue public, pas de site web, pas d'informations... Donc, si on ne
sait pas qu'un truc existe, il est difficile de le commander :-) S'ils
livrent sur une Business Livebox, avec une IP fixe ou un pool d'IP,
comme sur les offres filaires, çà peut être intéressant. Tout dépend du
prix...

--
Ceci étant, cela confirmerait la stratégie marketing consistant à
revendre des solutions techniques tierces (Konnect, Starlink) sous leur
propre marque. Cà me choque nettement moins que quand ils se mettent à
vouloir faire de la télévision, de la banque ou de la domotique (avec le
succès que l'on connait)...


--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] Coupure IpSEC sur liens Bouygues ?

[Jérôme Descoux via frnog]

Bonsoir,

Je confirme, flap au France IX Paris à ~10H20, et malgré la session up, trafic 
droppé.

J'ai clear hard vers 17H00 et tout est rentré en ordre mais ils ont shutdown 3 
minutes après.

Jérôme Descoux

> On 7 Nov 2023, at 20:07, Clément Cavadore  wrote:
> 
> Hello,
> 
> Je confirme avoir eu trois clients différents qui se sont plaint 
> d'injoignabilité chez Bouygues aujourd'hui. Probablement un incident au sein 
> de l'AS5410...
> 
> Clément Cavadore 
> 
> Le 7 novembre 2023 19:45:36 GMT+01:00, Erwan David  a 
> écrit :
>> Cet après-midi plusieurs clients nous ont signalé un problème de VPN IPsec 
>> down entre une IP Bouygues et une IP chez nous. De ntre côté on voyait bien 
>> les paquets ISAKMP sortant, mais aucun entrant (y compris aux intercos avec 
>> nos transitaires). Est-ce que quelqu'un a aussi constaté ce problème ?
>> 
>> (PS : les VPNs sont maintenant remonté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] [BIZ] Vendeur appliance pour OPNsense ?

[Jérôme Nicolle]

Claude,

Le 06/11/2023 à 16:08, DUVERGIER Claude a écrit :

Mais j'aurais aimé avoir des ports 2.5 Gbps pour être future-proof.


M-Gig ou 10Gb-T et "future-proof" dans la même phrase, il faut attendre 
vendredi pour ça.


Qu'est ce que tu veux faire avec ces machines que tu ne pourrais pas 
faire avec un mikrotik CCR2004 à 500 balles ?


@+

--
Jérôme Nicolle
+33 6 19 31 27 14


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

Re: [FRnOG] [BIZ] Recherche MUX EDFA ou OTN ou transport FC 32gb/s Paris PA3 PA4

[Jérôme Nicolle]

JC,

Prends donc une paire de Nokia Wavelite Access 200 avec 4 optiques 
100G-ER4, ou des Wavelite Metro 200 avec leurs CFP2. Mais entre PA3 et 
PA4 normalement en LR ça passe.


@+

Le 03/11/2023 à 16:52, JCLB a écrit :

Bonjour,

Je recherche assez rapidement une solution de transport de 4 liens Fibre 
Channel 32gb/s entre PA3 et PA4 à Paris.

Cela peut-être au choix :

   *   Location ou achat de MUX EDFA DWDM pour 13dB, (location n'importe quelle 
taille, achat 16 canaux de préférence) je gère les optiques et la dark fiber.
   *   Location ou achat d'OTN (uplink 100G pour loc, 200G+ pour achat) je gère 
la dark fiber
   *   Offre de transport éclairée pour 6 mois, via raccordement en cross-co 
equinix de préférence

L'objectif est de brancher des switchs SAN qui ne supportent pas du ER ou ZR, 
je peux donc mettre soit des optiques DWDM 10km qu'il faut amplifier en EDFA, 
soit du local vers châssis OTN.


La contrainte est de monter ça pour la première semaine de décembre.

Je suis joignable n'importe quand,
Jean-Charles BISECCO


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


--
Jérôme Nicolle
+33 6 19 31 27 14


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

Re: [FRnOG] [TECH] Provider mail pour collectivités

[GROS Jérôme - Wokifr]

https://www.amrf.fr/les-services/campagnol-fr/

Le 27/10/23 22:01, David Mercereau via frnog a écrit :

Bonjour Martin,

Si en plus de "juste avoir du mail" tu veux de l'éthique, tu pourrais 
adopter un C.H.A.T.O.N.S. , certain, propose 
du mail : https://www.chatons.org/search/by-service?field_alternatives_aux_services_target_id=385 
Au moins tu auras affaire à des humains, des Français... (tu augmentes 
les chances de possibilité de paiement par Chorus Pro...)


Belle journée,
David

https://retzo.net/
Tél port : 0663691604
Tél fix : 0972199940 Lundi|Mardi|Jeudi 9h30-16h ou Mercredi|Vendredi 9h30-12h

Le 27/10/2023 à 10:25, Martin a écrit :

Hello la liste,

je suis en train de revoir pas mal de choses dans ma petite municipalité
qui en a bien besoin, des fichiers critiques stockés sur le pc de la
secrétaire (sans backup, sans fermeture de session, et j'en passe) au
cahier papier de mots de passes posé sur le bureau avec une grosse
étiquette "mots de passe".
Oui je sais, les élections municipales datent, il est un peu tard pour s'y
mettre, mais il y avait des sujets prioritaires comme la branche de A qui
dépasse sur la parcelle de B qui est pas foutu d'aller lui demander
gentiment de la couper, voire de la couper lui même. Je m'égare (mais ça me
fait du bien bizarrement).

Bref, dans les sujets, il y a aussi un vieux mailmairie@wanadoo.fr  qui
est source de nombreux problèmes, car ne fonctionne pas 2 jours par mois,
tombe dans les spams, et j'en passe.

Je cherche donc une solution qui soit accessibles aux collectivités. Et par
là j'entends qui permette une facturation par Chorus Pro pour ce que j'en
sais. Si en plus elle est respectueuse de la vie privée des administrés qui
nous envoient des mails, c'est parfait. Evidemment on va en profiter pour
faire u mail 2.0 en remplaçantmairie@wanadoo.fr  àmai...@xxx.fr.

J'ai pas mis ça dans biz, parce qu'on va parler d'une facturation de
quelques euros par mois, et je ne pense pas finir chez un des "petits" qui
font vivre cette liste, plutôt un "moyen" chez qui je pourrai tout faire en
ligne, à la google mais avec la vie privée en plus.

Merci d'avance

Martin

---
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] Cogent perd mes paquets

[Jérôme Fleury]

Voila pourquoi:

"
Dear Cogent Customer,

At this time Cogent is experiencing several outages between Asia-Pacific to
NA and Asia-Pacific to EU. This triggered an automatic traffic convergence
for all MPLS services towards an alternative route. This is the expected
behavior of an MPLS IP network under this type of event. As a result,
customers may experience higher than usual latency/packet loss during peak
hours.
"

On Thu, Oct 26, 2023 at 2:50 AM Pierre LANCASTRE 
wrote:

> Bonjour
>
> On est pas encore vendredi, mais des gens ont aussi reçu un mail de sales
> demandant d'annoncer des préfixes sur des liens en prod (mais peu utilisés)
> ? J étais un peu surpris de voir passer ça.
>
> ++
>
> Pierre
>
>
> Le jeu. 26 oct. 2023, 5 h 44 a.m., ic  a écrit :
>
> > io,
> >
> > > On 23 Oct 2023, at 09:01, Stephane Bortzmeyer 
> wrote:
> > >
> > > Chez vous aussi ? Cela fait des semaines mais, ce matin, c'est plus
> > > que d'habitude (par exemple entre Gandi et Akamai).
> >
> > au hasard, un autre de leurs clients qui consomme plus que d’habitude ?
> >
> > La qualité de service chez eux ça fait longtemps qu’on n’essaye plus de
> > comprendre…
> >
> > ++ ic
> >
> >
> > ---
> > 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] SFR Business Team candidat au poste de la plus mauvaise hotline entreprise ?

[Jérôme Marteaux]

Le 25/10/2023 à 16:17, Nathan Delhaye a écrit :

Le mer. 25 oct. 2023 à 15:50, Toussaint OTTAVI  a
écrit :



Désolé, ce n'est pas Vendredi, mais là, je pense qu'on bat des records...



Candidat ? Je croyais qu'ils avaient déjà gagné haut la main ? (Oups
pardon, dredi c'est toujours pas aujourd'hui)

Plus tôt dans l'année, un monsieur très déprimé au téléphone m'a dit qu'ils
ne pouvaient pas livrer de fibre dans un bâtiment du 1er arrondissement de
Paris...

Une autre tout aussi déprimée m'a soutenue qu'il faut désormais que le PDG
de la société vienne signer en personne les contrats télécoms. ( Si c'est
pour une administration, ça marche comment ? Macron himself ? )



Peut-être qu'ils ne veulent plus de client, ce n'est pas un refus de vente !


La seule raison de contacter SFR c'est de migrer ailleurs...


On dirait que le LBO Altice arrive au bout du bout.
Après avoir transformé une propriété en loyer avec les points hauts, ils 
en sont à vendre les datacenters, même BFM serait à vendre.
Ca va tellement mal que Drahi souhaite vendre des participations dans 
SFR (participation sans en prendre le contrôle, qui souhaiterait ça ??).


Le seul département qui doit turbiner en ce moment chez SFR ça doit être 
le contrôle de gestion/légal pour contenir la déflagration de l'affaire 
Pereira:

https://www.lemonde.fr/economie/article/2023/09/16/altice-les-secrets-du-couple-drahi-pereira_6189634_3234.html

https://www.streetpress.com/sujet/1695982183-altice-patrick-drahi-milliard-armando-pereira-corruption-blanchiment-argent

Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] Problème lien ADSL/VDSL depuis lundi

[Jérôme Marteaux]

Le 19/10/2023 à 08:01, x.r...@sipleo.com a écrit :

Bonjour,

  


Est-on les seul à avoir des liens ADSL / VDSL via un fournisseur qui sont HS
depuis Lundi.

Ce n’est pas un problème de lien selon ce même fournisseur il s’agirait d’un
problème chez Orange.

C’est parfois facile de lui faire porter le chapeau souvent trop facile.

  


Apparemment, Orange détournerait la partie radius de l’authentification.

Du coup, n’étant pas connu sur leur serveur, le lien ne monte pas …

  


Ce qui m’étonnes et m’énerve un peu c’est que le problème on la depuis Lundi
8h.

Il aura fallu attendre hier matin (mercredi) pour s’entendre une réponse et
qu’en fait on n’est pas les seuls.

Mais comment est-ce possible de ne pas voir ça ?

C’est quoi leur système de supervision ?

Hier soir on nous annonce 24h à 48h

Si c’est avéré cela semble bien long, les experts c’est possible et si oui
c’est compliqué ?

  


Bref encore une fois ce fournisseur ne répond pas au ticket, gère son SAV
plus que mal (il n’est pas dans la galaxie Altitude Infra).

Heureusement reste un ou deux anciens que l’on peu joindre qui ont fait
avancer le sujet.

Sinon depuis qu’ils ont levé des fonds c’est vraiment déplorable.


Orange a 2 modes de livraison pour les A/VDSL/FTTH:
 - IP (ce que l'on toujours connu)
 - ethernet

IP utilise le chemin classique L2TP & radius avec une interco BGP.

Ethernet c'est le même principe que C2E, Orange met tout dans un VPLS et 
livre en layer 2 (même notion de plaque et de découpage par VLAN que 
C2E). Du coup il n'y a plus d'IP et de radius Orange, ça simplifie toute 
la chaîne et il y a moins de SPOF.

Cerise sur le gâteau, ça laisse le choix des realms.

Cette collecte est vachement plus pratique à gérer que la traditionnelle 
en IP.


Jérôme


--
Jérôme Marteaux


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

Re: [FRnOG] [ALERT] http SD* et cisco CVE-2023-20198

[Jérôme Berthier via frnog]

Le 19/10/2023 à 08:13, jehan procaccia INT a écrit :
Je m'interroge sur l'usage des interfaces [web|API|SD*]  prônées par 
les constructeurs


n'est-ce pas une exposition supplementaires majeure ? Ces outils (chez 
cisco DNA/Catalyst-center, SD-Acces/Wan ...)  utilisent-ils le service 
http/https ?


cf le CVE en cours qui semble faire de serieux degats :

https://www.it-connect.fr/cyberattaque-plus-de-34-000-equipements-cisco-pirates-avec-cette-nouvelle-faille-zero-day/ 



https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z 



https://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/ 





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


Bonjour,

Je pense qu'il ne faut pas mélanger.

Cette faille concerne la WebUI de management des équipements IOS-XE.

Elle est sensée ne pas être exposée n'importe comment (et même 
désactivée vu son peu d'utilité).


Sur SD-WAN, l'onboarding est fait de l'équipement (cEdge, vEdge) vers 
l'orchestrateur vBond (Validator) puis un contrôleur vSmart et le 
vManager sont découverts et le device s'y connecte.


A mon avis, s'il y a connexion entrante, elle est ensuite limitée aux 
contrôleurs (DTLS/OMP) et managers (SSH/NETCONF) validés et enrôlés par 
certificat. ça se passe sur des ports dédiés.


Toutefois, ce mécanisme reste faillible puisque là le point d'exposition 
est côté vBond Orchestrator (Validator exposé complètement pour recevoir 
l'onboarding et faire l'aiguillage) ou vSmart/vManage. Ils ont déjà eu 
leurs lots de failles critiques.


Pour SD-Access, à mon sens, c'est plus classique. DNA Center va venir 
découvrir les équipements en SNMP, SSH. Il y a sûrement aussi du ZTP 
possible (pas vérifié).


Bref, tout logiciel reste faillible donc quand tu exposes des points de 
découverte centralisée, ça peut forcément mal se passer.


--
Jérôme Berthier


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

RE: [FRnOG] [MISC] Troll pas troll sur la sécurité de vos accès.

[Jérôme Quintard]

Salut à tous,

Merci pour vos réponses.

Alors l'idée n'est pas d'être masochiste (@Jules) 🙂.

Très honnêtement hors OIV, je ne connais personne qui fasse réellement une 
isolation complète d'internet de leurs admins. La raison est simple : il y a de 
plus en plus d'administration d'équipements locaux ou d'applications qui se 
font sur l'internet. Les serveurs on premise devienne on cloud et souvent 
publique (Azure, GCP, AWS, etc.). Les admins utilisent des ITSM ou des 
gestionnaires de mots de passe sur l'internet. Avoir deux machines ou un 
bastion est peu exploitable dans les faits. Dès lors pourquoi se priver de 
mails...

S'isoler complètement d'internet (votre point de vue commun qui est 
effectivement un idéal... ou une utopie) est une gageure en soit que peu 
respecte scrupuleusement... je connais un OIV dans la défense dont les admins 
n'ont aucune difficulté à se balader sur internet tout en étant connecté en SSH 
sur un serveur de prod. Et j'en connais un autre qui respecte cette règle... 
mais pas entre 12 et 14h pendant la pause (chercher l'erreur).

Alors oui on peut mettre une ribambelle d'outil de détection de sécurisation 
(faut-il pouvoir se les payer ce que j'ai la chance de pouvoir faire dans notre 
groupe)... mais il n'empêche, sans cette isolation dont vous parlez et sans à 
minima un PAM (et le principe du PoLP) ou de techno type Microsoft Credential 
Guards, une machine sous Windows reste pour moi plus à risques avec le risque 
qu'un token soit ré-exploité.

Personnellement, je suis pratiquement certain de pouvoir entrer dans une grande 
partie des systèmes que je connais (ou pas) sur ce principe car une grande 
partie des admins sont sous Windows, ont accès à l'internet et on peu ou pas de 
MFA. Combien dans la liste sont dans ce cas précis... on le sera pas :)

Jérôme








____
De : Olivier Lange 
Envoyé : mercredi 18 octobre 2023 17:02
À : Jérôme Quintard 
Cc : frnog-m...@frnog.org 
Objet : Re: [FRnOG] [MISC] Troll pas troll sur la sécurité de vos accès.

La question d'autoriser ou non un OS est biaisée selon moi. C'est pas la que tu 
dois prendre tes mesures de sécurité (a conditions que tes machines soient bien 
à jour).. Il vaut mieux mettre en place des process sécuritaire, parmis ceux-ci:
- Séparation du compte à privilèges du compte "qui lit des mails" avec stockage 
du mot de passe dans une voûte
- Utilisation d'un bastion qui propose une rupture protocolaire, et idéalement 
qui gère l'accès au mot de passe (de cette manière, ton utilisateur 
s'authentifie sur ton bastion, et c'est le bastion qui lui connaît le mot de 
passe pour accéder à ta machine distante)
- Utilisation d'un MFA obligatoire pour tout comptes à haut privilèges (au 
moins, les autres devraient aussi...)
- Avoir une bonne protection périmètrique (NGFW) et t'assurer que ta zone users 
ne puisse pas accéder à ta zone à haut privilèges sans passer par un NGFW

Donc non, je n'interdit à aucun de mes admins d'accéder depuis un windows aux 
environnements sur lequel il doit travailler (pas le choix en plus, ils sont 
tous sous Windows...). Par contre je m'arrange pour qu'ils le fassent de 
manière sécurisée, en respectant autant que possible les modèles de type ZTNA, 
Least Privilges, etc...

Le mer. 18 oct. 2023 à 10:44, Jérôme Quintard 
mailto:jquint...@outlook.com>> a écrit :
Bon, j'aurai pu attendre vendredi, parce que la question risque d'être trollée 
à mort, mais allons y...

Au niveau SSI, autorisez-vous l'accès à vos équipes, à des équipements 
sensibles (réseaux comme systèmes) depuis une machine Windows ou limitez-vous 
ces accès depuis d'autres OS...

Prenons le cas d'un administrateur sous Windows (on va partir du principe qu'il 
n'est pas administrateur local, qu'il n'y a pas de PAM). Via du phishing, il se 
prend un mimikatz qui récupère dans la LSASS un token pour faire une élévation 
de privilèges. De là, l'ensemble du système est corruptible.

Par nature l'exploitation d'info pour faire du pass the hash/ticket, n'est pas 
exploitable sur d'autres OS même avec du realm... je ne trouve en tout cas rien 
sur le sujet...

Au delà, gérez-vous vos le AAA de vos équipements via un radius ou avec des 
credentials communs (pas glop) ou distincts (via un gestionnaire de mot de 
passe par exemple)...

Jerome

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

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

[FRnOG] [MISC] Troll pas troll sur la sécurité de vos accès.

[Jérôme Quintard]

Bon, j'aurai pu attendre vendredi, parce que la question risque d'être trollée 
à mort, mais allons y...

Au niveau SSI, autorisez-vous l'accès à vos équipes, à des équipements 
sensibles (réseaux comme systèmes) depuis une machine Windows ou limitez-vous 
ces accès depuis d'autres OS...

Prenons le cas d'un administrateur sous Windows (on va partir du principe qu'il 
n'est pas administrateur local, qu'il n'y a pas de PAM). Via du phishing, il se 
prend un mimikatz qui récupère dans la LSASS un token pour faire une élévation 
de privilèges. De là, l'ensemble du système est corruptible.

Par nature l'exploitation d'info pour faire du pass the hash/ticket, n'est pas 
exploitable sur d'autres OS même avec du realm... je ne trouve en tout cas rien 
sur le sujet...

Au delà, gérez-vous vos le AAA de vos équipements via un radius ou avec des 
credentials communs (pas glop) ou distincts (via un gestionnaire de mot de 
passe par exemple)...

Jerome

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

Re: [FRnOG] [BIZ] Pire que Cogent, ça existe...

[Jérôme Marteaux]

Le 13/10/2023 à 13:50, Paul Rolland (ポール・ロラン) a écrit :

Bonjour,

On Fri, 13 Oct 2023 13:43:57 +0200
David Ponzone  wrote:


Ca fait donc un prix par A environ 3 fois inférieur à un prix sur Paris
en ce moment.

Pour les pros du courant fort: je suppos qu’une infra de DC en 110V
coûtent moins cher qu’en 220V, ou je dis une connerie ?


Tiens, puisqu'on est en train de faire une bonne discussion de Dredi13, il
y a des DC qui propose du 48V ?
C'est interessant financierement ?


Je n'en ai vu que chez des opérateurs dont leur transmission était 
alimenté en 48V. Et les rares qui en avaient déployés ont tous arrêtés.


Côté hébergement, beaucoup se sont penché sur la question et il me 
semble que personne n'a déployé.


--
Jérôme Marteaux


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

Re: [FRnOG] [BIZ] Pire que Cogent, ça existe...

[Jérôme Marteaux]

Le 13/10/2023 à 09:48, David Ponzone a écrit :

Ben moi c’est un humain, basé à Fremont, qui m’a même expliqué qu’il n’était 
pas un bot.
Et 3 lignes plus bas, il me dit à nouveau qu’ils peuvent me proposer de la 
colo/transit dans leur DC de Fremont, qu’il me suffit d’envoyer mon matos et 
ils rackent pour moi.

A quel moment précis il comprend rien quand on lui dit qu’on cherche de la colo 
en France pour échapper à Equinix en France ?
Après, j’ai compris, c’est un ancien de Cogent :)
Le CV qui tue.

Bon, en tout cas, si quelqu’un veut de la colo à Fremont, c’est 400$/mois la 
baie avec transit 1G inclus, et ils rackent pour vous :)
On est contents d’apprendre qu’on se fait racketter en France.


Elec incluse ?
Je serais curieux de voir ce que ça donne côté énergie, fixe, variable ? 
Quel durée d'engagement ? Et quelle clause de révision des prix ?



Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] Orange Business et l'enfer du suivi de projet

[Jérôme Marteaux]

Le 13/10/2023 à 09:12, Toussaint OTTAVI a écrit :



Le 12/10/2023 à 17:31, Stéphane Rivière a écrit :
Le retraité, il avait son stock pirate sur l'île, planqué derrière 
quelques armoires d'URA. D'ailleurs ça lui avait été reproché, c'est 
dire la remarquable mentalité de cette 'entreprise'.


Oui, çà, malheureusement, c'est un grand classique de la boite ! Le tech 
qui avait le malheur de se faire choper à faire du "hors process", il se 
faisait démonter par la hiérarchie ! Surtout si le client avait eu le 
malheur de faire une plainte, parce que là, le lampiste était tout 
trouvé :-(


Enfin, çà, c'était surtout vrai à l'époque du gros lard dont le 
management a poussé plusieurs personnels au suicide ! Il a, me semble 
t-il, été condamné pour harcèlement moral; mais sa légion d'honneur ne 
lui a pas pour autant été retirée, et çà n'a pas fait revenir ceux qui 


Breloque inintéressante distribuée comme hochet à n'importe qui.
La vraie médaille c'est celle-ci: 
https://fr.wikipedia.org/wiki/M%C3%A9daille_d%27honneur_des_PTT


ont décidé de mettre fin à leurs jours à cause de leur job ! C'est un 
truc qui m'a toujours sidéré : comment on peut, sournoisement, 
insidieusement, pousser un salarié consciencieux à commettre un tel acte 
extrême ? Je l'ai vécu de l'extérieur, car j'avais régulièrement envie 
d'en prendre un pour taper sur l'autre. J'ai compris bien plus tard 
pourquoi. Et j'en ai même regretté les pressions que j'ai pu leur 
mettre, parfois...


Ceci étant, il me semble bien que tout cela a été relégué aux rangs du 
passé. On sent bien qu'une sorte de carcan hiérarchique est toujours 
présent, mais pas plus que dans toute grande boite, et en tout cas, rien 
qui ne puisse se surmonter par des relations professionnelles normales, 
et un peu de vocabulaire ornithologique :-D




En fait c'est pas si vieux que ça car le procès en appel s'est ouvert en 
mai 2022 et délibéré septembre 2022, ça a donc tout juste 1 an.


Le récit du procès et du travail chez France Telecom en ces années est 
assez édifiant: https://www.histelfrance.fr/page-5ce9200a59409.html


Un parallèle peut être fait avec Alcatel.


PS: pour la médaille, c'est râpé pour la plupart d’entre-nous, elle 
n'est attribuée qu'aux fonctionnaires et agents publics !



Jérôme


--
Jérôme Marteaux


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

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

[Jérôme Quintard]

Je n’ai pas tout lu mais dans ce cas ça semble plus un problème de sélectivité 
si ton souci provient du réarmement d’un circuit en amont. Qu’en dis ton 
électricien ?

> Le 10 oct. 2023 à 09:53, fr...@r0m5.eu a écrit :
>
> Bonjour,
>
> Comme évoqué dans un autre mail, le type de courbe semble plus impactant pour 
> un problème éventuel de courant d'appel qu'un problème de courant de fuite.
> Par ailleurs, nous sommes déjà sur un différentiel Type A SI mais merci pour 
> le retour !
>
> Bonne journée,
>
>> Le 09/10/2023 à 20:07, Pierre-E a écrit :
>> Bonjour,
>>
>> Sais-tu sur quel type de courbe son tes disjoncteurs ?
>> J’ai eu quelques problèmes du même type et après être passé sur des ASi, le 
>> problème était résolu.
>>
>> My two cents,
>> Pierre-Emmanuel LT
>>
 On 9 Oct 2023, at 19:18, fr...@r0m5.eu wrote:
>>>
>>> Bonsoir,
>>>
>>> Je rencontre actuellement un soucis dans une baie informatique avec une 
>>> arrivée 32A, hors datacenter, qui dispose d'un PDU manageable d'une marque 
>>> reconnue et présente sur le marché datacenter.
>>>
>>> Nous essayons d'utiliser ce PDU en y reliant 15 alimentations de switch 
>>> réseau 350W (pas junisco mais grande marque réseau tout de même) qui ont 
>>> chacune un peu plus de 1mA de courant de fuite.
>>> Lorsque nous relions ces alimentations au PDU déjà démarré (contrôleur 
>>> démarré et outlets déjà alimentées) pas de soucis.
>>> Par la suite lorsque le courant est coupé en amont du PDU, alors au retour 
>>> du courant notre différentiel 30mA saute systématiquement.
>>> Nous avons mesuré que lors du démarrage du PDU, on a un courant de fuite de 
>>> 8 à 10mA supplémentaires, courant de fuite qui disparaît une fois le 
>>> contrôleur du PDU démarré et les relais actionnés (les outlets alimentées). 
>>> On revient alors au seul courant de fuite des alims de switch (entre 15 et 
>>> 20 mA).
>>>
>>> Concernant le fait que le courant de fuite soit plus important au démarrage 
>>> du PDU qu'une fois celui-ci démarré, j'ai contacté le constructeur et 
>>> j'attends un retour.
>>>
>>> J'en arrive aux questions :
>>> - 1 mA de courant de fuite par alim de switch vous paraît-il cohérent ? 
>>> Nous savons testé avec une autre marque, nous sommes plutôt aux alentours 
>>> de 0,5mA.
>>> - des différentiels 30mA sont-ils à votre connaissance utilisés en 
>>> datacenter ? un différentiel pour chacune des deux sources d'alim redondées 
>>> d'une baie ? J'aurai tendance à penser que oui pour la protection des 
>>> personnes mais dans un job précédent nous remplissions bien nos baies dans 
>>> nos datacenters parisiens et nous n'avons jamais à ma connaissance eu de 
>>> problème de différentiel qui saute.
>>>
>>> Si par ailleurs vous avez d'autres suggestions qui pourraient m'être 
>>> utiles, je suis preneur.
>>>
>>> Bonne soirée !
>>>
>>>
>>> ---
>>> 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] recherche solution pour emballer des routeurs en chassis sur palette

[Jérôme Nicolle]

Hello !

Chez Alternative Partners Solutions / Midrange Group il y a des 
flightcase sur mesure pour transporter des équipements 19".


En terme pratique, ils vont shipper les flightcase vides au DC, tu les 
récupère et y fixe tes équipements, ils vont faire récupérer le 
flightcase plein (généralement via transporteur genre DHL ou FedEx, 
c'est un peu cher), et l'envoyer où tu veux, puis le faire récupérer une 
fois vide.


Ils font ça depuis plus de 20 ans pour pas mal de types de machine, ça 
marche vraiment bien.


@+

Le 11/10/2023 à 14:05, Clement Cavadore a écrit :

Hello la liste !

J'aurais besoin prochainement d'emballer à Paris trois chassis sur une
ou deux palettes: 2x Juniper MX480 (8U x2) et 1x Juniper MX240 (5U),
afin de les faire ensuite enlever par un service de transport type DHL
ou UPS.

Est-ce que quelqu'un aurait une idée de comment procéder? Je ne suis
absolument pas équipé pour faire ce genre de choses, et les routeurs se
trouve(ron)t dans un domicile perso. Si éventuellement quelqu'un a de
quoi faire l'emballage dans sa société et accepter de les stocker un ou
deux jours le temps de faire passer la société de transport, je suis
ouvert aux propositions pour les emmener sur place :)

Merci par avance pour les idées !

Bien à vous,

Clément Cavadore


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


--
Jérôme Nicolle
+33 6 19 31 27 14


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

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

[Jérôme Quintard]

Nous on mets systématiquement du courbe D ou K et aucun souci du genre.

Une autre technique que l’on utilise c’est de temporiser d’une seconde chaque 
prise électrique par rapport à la suivante ce qui évite aussi pas mal de 
contrainte.

> Le 9 oct. 2023 à 19:54, fr...@r0m5.eu a écrit :
>
> Bonsoir Richard,
>
> Actuellement aucun câble réseau n'est branché.
> En connectant moins d'équipements le problème est toujours présent, mais avec 
> 12 alimentations ou moins ça passe : on a le même phénomène mais on reste 
> sous la valeur qui fait sauter le différentiel.
>
> Romain
>
>> Le 09/10/2023 à 19:30, Richard Klein a écrit :
>> Bonsoir
>>
>> -as tu tenté de déconnecté tous les câbles réseaux de tes switchs?
>> -le problème est il toujours présent .
>>
>> Si le problème est toujours présent tente de déconnecter un switch à la fois 
>> et vérifier si le problème est toujours présent?
>>
>> Une fois j’avais un équipement qui avait un problème similaire et l’un des 
>> câbles réseaux était dénudé dans le chemin de câble métallique avec 
>> possiblement un problème de mise à la terre.
>>
>> Richard
>>
>> Envoyé de mon iPhone
>>
 Le 9 oct. 2023 à 19:19, fr...@r0m5.eu a écrit :
>>>
>>> Bonsoir,
>>>
>>> Je rencontre actuellement un soucis dans une baie informatique avec une 
>>> arrivée 32A, hors datacenter, qui dispose d'un PDU manageable d'une marque 
>>> reconnue et présente sur le marché datacenter.
>>>
>>> Nous essayons d'utiliser ce PDU en y reliant 15 alimentations de switch 
>>> réseau 350W (pas junisco mais grande marque réseau tout de même) qui ont 
>>> chacune un peu plus de 1mA de courant de fuite.
>>> Lorsque nous relions ces alimentations au PDU déjà démarré (contrôleur 
>>> démarré et outlets déjà alimentées) pas de soucis.
>>> Par la suite lorsque le courant est coupé en amont du PDU, alors au retour 
>>> du courant notre différentiel 30mA saute systématiquement.
>>> Nous avons mesuré que lors du démarrage du PDU, on a un courant de fuite de 
>>> 8 à 10mA supplémentaires, courant de fuite qui disparaît une fois le 
>>> contrôleur du PDU démarré et les relais actionnés (les outlets alimentées). 
>>> On revient alors au seul courant de fuite des alims de switch (entre 15 et 
>>> 20 mA).
>>>
>>> Concernant le fait que le courant de fuite soit plus important au démarrage 
>>> du PDU qu'une fois celui-ci démarré, j'ai contacté le constructeur et 
>>> j'attends un retour.
>>>
>>> J'en arrive aux questions :
>>> - 1 mA de courant de fuite par alim de switch vous paraît-il cohérent ? 
>>> Nous savons testé avec une autre marque, nous sommes plutôt aux alentours 
>>> de 0,5mA.
>>> - des différentiels 30mA sont-ils à votre connaissance utilisés en 
>>> datacenter ? un différentiel pour chacune des deux sources d'alim redondées 
>>> d'une baie ? J'aurai tendance à penser que oui pour la protection des 
>>> personnes mais dans un job précédent nous remplissions bien nos baies dans 
>>> nos datacenters parisiens et nous n'avons jamais à ma connaissance eu de 
>>> problème de différentiel qui saute.
>>>
>>> Si par ailleurs vous avez d'autres suggestions qui pourraient m'être 
>>> utiles, je suis preneur.
>>>
>>> Bonne soirée !
>>>
>>>
>>> ---
>>> 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] Cable alimentation verouillable

[Jérôme Quintard]

Merci Amel pas le même prix !

Le 2 oct. 2023 à 17:14, Armel Chargé-Chauvet // frekences  
a écrit :


Le bon vieux FS ? -> https://www.fs.com/products/155411.html



Le 2 oct. 2023 à 15:24 +0200, Jérôme Quintard , a écrit :
Hello,

Cisco me casse les bonbons... avec leur câble C15 en lieu et place du 
traditionnel C13.

Je cherche des verrouillables (genre Zlock) de noir et de couleur (rouge ou 
orange).

J'ai trouvé chez GMI Databox des câbles de 2m, mais pour la bagatelle de 44€HT 
le câble.

Est-ce que vous avez des prestataires moins chers dans vos contacts, même s'ils 
habitent sur mars...

Jérôme





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

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

[FRnOG] [MISC] Cable alimentation verouillable

[Jérôme Quintard]

Hello,

Cisco me casse les bonbons... avec leur câble C15 en lieu et place du 
traditionnel C13.

Je cherche des verrouillables (genre Zlock) de noir et de couleur (rouge ou 
orange).

J'ai trouvé chez GMI Databox des câbles de 2m, mais pour la bagatelle de 44€HT 
le câble.

Est-ce que vous avez des prestataires moins chers dans vos contacts, même s'ils 
habitent sur mars...

Jérôme





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

Re: [FRnOG] [MISC] Abuse Scaleway/Online

[Jérôme Marteaux]

Est-ce qu'on pourrait comparer la qualité de ces formulaires avec les 
nombreux formulaires que les nombreuses administrations mettent en place 
depuis de nombreuses années ? (sarcasme)


Remarquez que le public a fait beaucoup d'effort ces derniers mois afin 
d'améliorer leurs fonctionnements et que finalement c'est possible de 
faire des formulaires web qui s'adressent à Mme Michu et qui embrayent 
sur un vrai process !




Jérôme


Le 21/09/2023 à 19:07, David Ponzone a écrit :

Ouais donc on est plusieurs à se plaindre de la mauvaise volonté de ces gens, 
qui semblent penser qu’on peut empocher les revenus d’une activité de masse, 
sans pour autant supporter les coûts des emmerdes qui viennent avec l’activité 
de masse.


Le 21 sept. 2023 à 18:59, Guillaume GARNIER via frnog  a écrit 
:

Leur formulaire ne reconnaît même pas certaines IPs leur appartenant.

Dans une aventure précédente avec eux, il fallait lire entre les lignes pour 
comprendre qu'ils allaient filer mon adresse mail à leur client spammeur afin 
qu'ils me retirent de leur liste - fumisterie, le mot est faible. Quoique, 
j'imagine sans mal que cette pratique est assez répandue/contagieuse.

Et ovh, tiens. Eux, c'est encore mieux : vous leur transférez un spam avec les 
entêtes en haut du mail et ils vous répondent _dans la seconde_ que vous n'avez 
pas fourni les informations nécessaires au traitement. Allez sur le formulaire 
blablabla... ^^



--
Jérôme Marteaux


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

Re: [FRnOG] [MISC] interconnexions entre opérateurs : commen =?UTF-8?Q?t=20=C3=A7a=20marche??=

[Jérôme Marteaux]

 veulent pas ?) les facturer. Je pense même que les 
numéros surtaxés n'existent que chez nous d'où la difficulté de les 
refacturer à l'appelant qui n'en connaît pas le principe.


La contrainte légale existe aussi, certains pays imposent (par une loi) 
que toutes les communications entrantes et sortantes d'un pays passent 
exclusivement par un opérateur (désigné par l'Etat).

Ainsi les communications sont mieux surveill^Wsécurisées.

Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [BIZ] Déstockage Sniffing

[Jérôme Nicolle]

Plop,

Tiens, je serais bien intéressé par un onduleur tri 12kV pour mon 
nouveau labo. Pas forcement besoin besoin de batteries, j'ai de la dispo 
en local, mais j'ai besoin de fonctionner en double conversion.


Vous auriez un truc sous la main ?

@+

--
Jérôme Nicolle
+33 6 19 31 27 14


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

Re: [FRnOG] [MISC] Foudre

[Jérôme Quintard]

J’ai fait un PowerPoint avec des photos de ce que l’on a pu observer. Si ça 
vous tente d’y jeter un coup d’œil. Le plus bluffant dans l’histoire c’est que 
seule une paire dans un câble FTP est en court circuit.

J’arrive même pas à comprendre qu’il y a pas plus de dégât voir même comment 
c’est possible.


Incident Foudre.pptx
we.tl
[apple-touch-icon-180x180.png]


Le 28 août 2023 à 18:03, Philippe ASTIER via frnog  a écrit :

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

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

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

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

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

Il y en a un qui va assez loin dans la théorie en parlant aussi des volumes 
protégés, etc… c’est Dehn 
(https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dehn.fr%2F&data=05%7C01%7C%7Cf53e5104dc3f436d54ca08dba7e05682%7C84df9e7fe9f640afb435%7C1%7C0%7C638288354184052153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8Dj3asbiV1MajkKVJGA5bHX2u6Ndvo7zBE4sRiqC1Kk%3D&reserved=0
 et 
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dehn.fr%2Ffr%2Fcatalogues&data=05%7C01%7C%7Cf53e5104dc3f436d54ca08dba7e05682%7C84df9e7fe9f640afb435%7C1%7C0%7C638288354184052153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=51w8Lf1rxKQATyXKYpiiNUDDpVFN52gIaFDgzy4%2BzVU%3D&reserved=0).
Bon ils vendent non seulement tout ce qu’il faut, mais aussi leur service. Pour 
le coup, ils vont plus loin que les généralistes que j’ai mentionnés.



---
Liste de diffusion du FRnOG
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F&data=05%7C01%7C%7Cf53e5104dc3f436d54ca08dba7e05682%7C84df9e7fe9f640afb435%7C1%7C0%7C638288354184052153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oaC6d5POJU3zUgC3YWgPVmyThKSiCB6%2FqGi7bQH3Cq0%3D&reserved=0

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

Re: [FRnOG] [TECH] Distance MINIMUM pour utilisation fibre monomode et sfp 10G

[Jérôme Marteaux]

Le 28/08/2023 à 16:12, David Ponzone a écrit :

Cela confirme qu’à part le ZR, le seul moment où on PEUT avoir un problème, 
c’est quand les SFP de chaque côté ne sont pas du même constructeur (et donc 
potentiellement, le RX max d’un côté peut être trop bas).


Pour appuyer le propos, en fait il n'y a que très peu de constructeurs, 
les vendors posent juste leurs étiquettes. Donc globalement tous les SFP 
ont les mêmes caractéristiques et tu peux partir sur des poseurs 
d'étiquettes différents du moment qu'ils ont les mêmes longueurs d'ondes 
à l'émission et à la réception.


Parfois il y a des vendors très obtus dont l'OS refuse d'utiliser des 
optiques qui ne sont pas de la marque, tu es donc obligé d'avoir des 
SFP/SFP+/whatever de vendor différents et ça fonctionne très bien.


Tips: communément les poseurs d'étiquettes utilisent cette 
classification selon la puissance d'émission et la sensibilité de 
réception et généralement les caractéristiques sont les mêmes d'un 
poseurs d'étiquettes à un autre: SR, LR, ER puis ZR.


Tout ce qui n'est pas ER et ZR n'ont pas besoin d'atténuateur si tu les 
met l'un en face de l'autre avec 1m de distance.




Perso, même avec des cross-co venant d’équipements tiers, j’ai eu une seule fois 
le problème (RX un peu au-dessus du warning level sur un Cisco) >


Souvent le budget optique d'une liaison (une paire de fibre) n'est pas 
exactement le même d'une fibre à l'autre (qualité des soudures, propreté 
des connecteurs dans les MMR ...).


Jérôme

--
Jérôme Marteaux


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