[FRnOG] [TECH] Fin de vie ISC DHCP relay

[Louis Scalbert]

Bonjour à tous,

ISC DHCP relay n'est plus maintenu.
https://www.isc.org/blogs/dhcp-client-relay-eom/
Autant pour le serveur, ISC a sorti Kea DHCP mais n'a rien prévu pour le
relai.

Qu'utilisez-vous comme relai Open-source ? Qu'avez-vous essayé ? Quels sont
vos retours ?

cordialement,

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

Re: [FRnOG] [MISC] Hébergeur Mail Perso : Bien choisir

[Louis G. via frnog]

Hi everyone,

Après une dizaine de réponses je vois que personne n'a cité Migadu.
https://migadu.com

Petit hébergeur basé en Suisse (serveurs en France, il propose des
offres à l'usage. En gros tu paie pas au nombre de domaines, d'alias ou
d'options, mais au stockage. Pour 5 Go tu t'en sors pour ~10€/mois.
Y'a aussi des limites quotidiennes d'envoi/reception, assez larges.
https://migadu.com/pricing/

> D'un point de vue fonctionnel, rien d'exceptionnel, au moins 2 NDD
> personnalisés, 1 boite partagés, gestion des alias '+', Catch-All, au moins
> 2 email / users, 5Go mini

Aucun soucis là dessus, tu peux faire à peu près ce que tu veux. Tu peux
même faire du "pattern rewrite" pour que `machin.bidule` tombe dans la boite
"machin" (et éviter que les sites qui refusent l'usage du + dans les
adresses te disent d'aller te faire cuire un œuf (oui ça existe…))

> et si possible un support des standards mails
> simili exchange (synchro mail + agenda, contact et notes, à la Krosof't,
> Googleuh, iPomme)

Bon par contre c'est là où le bas blesse, Migadu fait exclusivement du mail.
Pas de WebDAV ou autre… À voir si c'est un no-go pour toi.
Edit : en fait je suis allé vérifier et en fait si, c'est accessible. Par
contre c'est précisé que c'est pas la priorité donc c'est les trucs de base

> We continue developing them but please do not expect we will ever compete
> with dedicated calendar services.


Pour le reste j'en suis très satisfait, depuis 3~4 ans environ. On est 5
à profiter de l'abonnement, j'ai zéro soucis à remonter.

Quelques trucs cool à citer :
- support des filtres sieve
- 10/10 sur mailtester (en suivant la config conseillée pour les DNS)
- le panel admin qui est vraiment bien foutu
- le support qui est à l'écoute et compétent

À propos de support, le service est suffisament plébiscité pour que
l'outil de ticketing propose la catégorie "compliment"


Et si t'es pas convaincu, le site propose une page dédiée à tous les
points négatifs, donc même là dessus y'a de la transparence. :)
https://migadu.com/procon/


My 2 cents.

Louis


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

[FRnOG] [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail

[Louis Poidevin via frnog]

La vraie si possible. ^^


--- Original Message ---
Le lundi 26 juin 2023 à 13:53, Stephane Bortzmeyer  a écrit :


> 

> 

> On Mon, Jun 26, 2023 at 11:50:06AM +,
> Louis Poidevin via frnog frnog@frnog.org wrote
> 

> a message of 105 lines which said:
> 

> > Ma question est donc la suivante : connaissez-vous les raisons pour
> > lesquelles les entreprises, même les hébergeurs mail, s'en tiennent
> > à l'IPv4 uniquement ?
> 

> 

> Il faut une réponse bienveillante ou bien il faut la vraie ? :-)
> 

> 

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

signature.asc
Description: OpenPGP digital signature

[FRnOG] [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail

[Louis Poidevin via frnog]

Bonjour,

En faisant des recherches sur l'état de l'art des infrastructures mail, j'ai 
remarqué que très peu de domaines d'entreprise supportent la réception de mail 
en IPv6.Que ce soit orange, protonmail, ovh pour n'en citer que quelques uns, 
aucun d'entre eux ne semble avoir d'IPv6 sur leur MX. Le seul que j'ai trouvé 
jusqu'à présent est gmail.


Il aurait pu y avoir du dual-stack, mais rien.

Et en faisant des recherches sur le sujet, je suis tombé sur un article 
expliquant que des outils existent pour ce genre d'infa : 
https://labs.ripe.net/author/mirjam/sending-and-receiving-emails-over-ipv6/

Ma question est donc la suivante : connaissez-vous les raisons pour lesquelles 
les entreprises, même les hébergeurs mail, s'en tiennent à l'IPv4 uniquement ?

Merci d'avance,
Louis Poidevin

signature.asc
Description: OpenPGP digital signature

RE: [FRnOG] [TECH] Juniper EX2300 - Utilisation de l'interface web J-Web ?

[BELLOTTO Louis]

Hello,

Quand je suis passé de cisco à juniper (en 2015), on m'a aussi vanté le J-Web.
Je ne suis jamais arrivé à travaillé serieusement avec.

Pour moi, tout ce qui est commutateuers et routeurs (et ... ) : du cli !

Après, ce n'est pas parceque tu as une interface web, que tu vas savoir 
configurer du bgp ou du lag ;)



--

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Toussaint 
OTTAVI
Envoyé : jeudi 8 juin 2023 10:20
À : frnog@frnog.org
Objet : [FRnOG] [TECH] Juniper EX2300 - Utilisation de l'interface web J-Web ?

Bonjour la liste,

Je m'initie actuellement aux switches Juniper. Il y a toujours des nouvelles 
choses à apprendre dans notre métier, même pour les vieux comme moi ;-)

On est bien d'accord sur le fait que le CLI est indispensable pour maîtriser 
toutes les fonctions. Cependant, je m'intéresse également à l'interface 
d'administration web (J-Web + Application Package), afin que mes collègues non 
spécialisés puissent effectuer des opérations basiques comme remplacer un 
switch défectueux, y injecter une config, ou taguer / détaguer des VLANs 
suivant les besoins, le tout en mode web, sans passer par un câble console.

Mes tous premiers essais avec J-Web ne sont pas très concluants. Bien que 
l'interface soit claire et assez bien organisée, on a l'impression que ce n'est 
qu'une sur-couche pas tout à fait finie, pas trop testée, ou pas conçue pour çà 
:
- Avec le EZ Setup Web, je n'ai pas réussi à changer l'adresse IP :-D 
Apparemment, il essaye de commiter l'IP fixe que je lui donne, mais sans 
supprimer le précédent paramétrage DHCP; donc le commit foire lamentablement :-)
- Pas possible d'uploader l'Application Package, car il n'y a plus assez de 
place. Or le mini-gestionnaire de fichiers se trouve précisément dans 
l'Application Package; dans le J-Web Basic, il n'y a rien pour faire le ménage 
dans les anciennes versions / fichiers temporaires; donc, c'est CLI 
indispensable.
- Avec une approche full-CLI, j'arrive bien à faire à peu près ce que je veux, 
mais je n'ai pas réussi à activer le serveur web J-Web ! Le service semble bien 
activé suivant la doc, mais on ne peut pas s'y connecter !

D'où ma question :
Le module J-Web + Application Package est-il vraiment pertinent pour permettre 
à des utilisateurs de base d'effectuer des manipulations simples ? Ou bien 
dois-je me concentrer uniquement sur le CLI, et réserver ces switches à des 
endroits où la technicité est requise ?

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

-
 Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce 
message non conforme à sa destination, toute diffusion, copie ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
préalable. Son contenu ne saurait constituer en aucun cas un engagement 
contractuel, une offre de souscrire à quelconque produit ou instrument 
financier ou une sollicitation à investir de la part du Groupe La Française et 
toutes opinions exprimées dans ce message ne sauraient nécessairement refléter 
celle du Groupe La Française. Le contenu de cet email peut contenir des virus 
informatiques qui pourraient endommager votre système informatique. Bien que 
Groupe La Française ait pris toutes les précautions raisonnables pour minimiser 
ce risque, nous déclinons toute responsabilité pour tout dommage que vous 
pourriez subir en raison de virus informatiques. Si vous recevez ce courriel 
par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. 
Nous vous invitons à prendre connaissance de notre politique de confidentialité 
et de cookies en cliquant ici 
https://www.la-francaise.com/fr/politique-de-confidentialite-et-de-cookies/ 
-
 This message and any attachments are confidential and may be legally 
privileged or otherwise protected from disclosure. It is intended only for the 
stated addressee(s). Any use, dissemination, copy or disclosure of this message 
not in accordance with its purpose, either in whole or in part, is prohibited 
without our prior formal approval. Its contents, given solely for information, 
does not constitute a commitment or an offer to subscribe to any financial 
product by La Française Group. Any opinion expressed in this email may not 
necessarily reflect the opinion of La Française Group. The content of this 
email may contain computer viruses that could damage your computer system. 
Although La Française Group has taken all reasonable precautions to minimize 
this risk, we decline any liability for any damage you may suffer due to 
computer viruses. If you are neither the addressee nor an authorized recipient 
of this message, please notify the sender 

[FRnOG] [JOBS] [JOBS] [BAYONNE] Administrateur Système - DevOps chez l'opérateur/hébergeur IZARLINK/IZARHOST

[Jean-Louis Mélin]

Bonjour à tous

Nous recherchons un administrateur Système DevOps avec une première expérience 
significative dans la gestion/infogérance de services Cloud pour compléter nos 
offres de connectivité.

Titre du poste : Administrateur Système DevOps / Responsable de nos Services 
Cloud H/F
Type de contrat : CDI  - 35h - Semaine de 4 jours
Localisation : Technopole Izarbel - Bidart - Côte Basque (64)
L'entreprise : le groupe Izarralde est leader des infrastructures numériques de 
proximité en Sud Aquitaine. Nous intégrons de façon unique l'opérateur de 
proximité (izarLink) et l'hébergeur (izarHost) qui propose des services Cloud 
de proximité. Nous sommes fiers de nos valeurs (proximité, développement du 
territoire, numérique humain, respect de l'environnement) et développons des 
solutions innovantes pour les entreprises & collectivités du Pays Basque, 
Landes et Béarn.

Les missions :
1 / Adaptations de nos offres Cloud en mode « agile »
* Tests en continu de nos offres et de leurs évolutions
* Dimensionnement nécessaire aux offres : configurations 
matérielles / logicielles
* Usages : suivi des pilotes / évaluation des fonctionnalités / 
développements complémentaires
2 / Améliorer la mise en production de nos solutions
* Déploiement automatisé
* Intégration dans l'outil de supervision Zabbix
* Création de supports de formation interne et Client
3 / Gérer le support Client
* Encadrement d'une équipe de techniciens support
* Gestion des demandes d'assistance de niveau 2

Votre profil :
Vous êtes titulaire d'un diplôme de niveau Bac+5 et vous justifiez d'une 
expérience professionnelle d'au moins 5 ans.
Vous êtes passionné de solutions OPEN SOURCE et souveraines.
Vous avez de réelles capacités en mangement d'équipe et un sens aigu du service 
Client.
Compétences techniques :
- Parfaite maîtrise des OS serveurs Linux/Windows, virtualisation KVM/VMware, 
automatisation et scripting, serveurs TOIP Asterisk, Bases de données SQL, 
Serveurs de messagerie ...
- La connaissance des offres Cloud AWS, Azure, Google Cloud Platform est un plus
- Bonnes connaissances des technologies réseau VLAN, routage OSPF/BGP, infras 
opérateurs WDM/MPLS ... pour dialoguer avec nos experts réseaux
- Bonnes connaissances en CyberSécurité Firewall NG, protection mail, EDR, 
Sauvegarde, SIEM  pour dialoguer avec nos experts sécurité

Rémunération : selon profil et expérience
Poste fortement évolutif

N'hésitez pas à me contacter par mail pour plus d'informations

Cordialement
Jean-Louis Mélin
jlme...@izarlink.com<mailto:jlme...@izarlink.com>

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

RE: [FRnOG] [TECH] Migration Office

[BELLOTTO Louis]

Hello,

Il faut installer un "serveur de déploiement" pour Office 2019.
https://learn.microsoft.com/en-us/deployoffice/office2019/deploy





-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Jeff 
PAPAZIAN
Envoyé : mercredi 23 novembre 2022 11:40
À : Toussaint OTTAVI 
Cc : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] Migration Office

[Vous ne recevez pas souvent de courriers de jfpapaz...@gmail.com. Découvrez 
pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]

Bonjour

Moi également .
Je vais tenter de glaner des informations car à ce jour j ai la majorité de l 
infra citrix reposant évidemment sur Windows server et si effectivement office 
ne peut plus être fourni de cette manière cela pose un vrai problème .
Si certains ont plus d infos.

Bonne journée

> Le 22 nov. 2022 à 15:33, Toussaint OTTAVI  a écrit :
>
> 
>
>> Le 21/11/2022 à 12:11, Julien Issler a écrit :
>> Un point intéressant : les applications 365 ne seront plus supportées / 
>> utilisables sur Windows server dès l'automne 2025, et à ce jour le support 
>> sur 2022 n'est qu'en preview.
>>
>> https://learn.microsoft.com/en-us/deployoffice/endofsupport/windows-server-migration
>>
>> Ça sent la fin du RDS traditionnel, au profit du VDI, de préférence (pout 
>> MS) chez Azure.
>
> Diantre ! Je viens de renouveler mon contrat Microsoft SPLA, mais à aucun 
> moment, personne n'a daigné me parler de ce "détail" ! Merci pour l'info !
>
> Que Microsoft incite les clients qui n'y comprennent pas grand chose à 
> héberger chez elle, avec ses propres tarifs prohibitifs, je n'ai rien contre 
> ;-) Mais là, çà voudrait dire qu'un client ne pourrait plus utiliser Office, 
> ni sur ses propres serveurs RDS, ni sur les nôtres (pour les clients à qui 
> nous proposons du Cloud Privé) ?
>
> J'espère avoir mal compris ou mal interprété. Sinon, il va falloir attendre 
> au moins une semaine des 4 Vendredis pour que je puisse exprimer le fond de 
> ma pensée :-) Et que j'aille acheter de la vaseline en fût :-)
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

-
 Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce 
message non conforme à sa destination, toute diffusion, copie ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
préalable. Son contenu ne saurait constituer en aucun cas un engagement 
contractuel, une offre de souscrire à quelconque produit ou instrument 
financier ou une sollicitation à investir de la part du Groupe La Française et 
toutes opinions exprimées dans ce message ne sauraient nécessairement refléter 
celle du Groupe La Française. Le contenu de cet email peut contenir des virus 
informatiques qui pourraient endommager votre système informatique. Bien que 
Groupe La Française ait pris toutes les précautions raisonnables pour minimiser 
ce risque, nous déclinons toute responsabilité pour tout dommage que vous 
pourriez subir en raison de virus informatiques. Si vous recevez ce courriel 
par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. 
Nous vous invitons à prendre connaissance de notre politique de confidentialité 
et de cookies en cliquant ici 
https://www.la-francaise.com/fr/politique-de-confidentialite-et-de-cookies/ 
-
 This message and any attachments are confidential and may be legally 
privileged or otherwise protected from disclosure. It is intended only for the 
stated addressee(s). Any use, dissemination, copy or disclosure of this message 
not in accordance with its purpose, either in whole or in part, is prohibited 
without our prior formal approval. Its contents, given solely for information, 
does not constitute a commitment or an offer to subscribe to any financial 
product by La Française Group. Any opinion expressed in this email may not 
necessarily reflect the opinion of La Française Group. The content of this 
email may contain computer viruses that could damage your computer system. 
Although La Française Group has taken all reasonable precautions to minimize 
this risk, we decline any liability for any damage you may suffer due to 
computer viruses. If you are neither the addressee nor an authorized recipient 
of this message, please notify the sender of receipt immediately and delete 
this message from your system. We invite you to read our privacy and cookies 
policy available on the Group’s website by clicking here 
https://www.la-francaise.com/en/privacy-and-cookies-policy/ 
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] RE: [BIZ] Matériel Cisco Meraki

[BELLOTTO Louis]

Je vais envoyer la liste détaillée aux personnes intéressées.

Pour l'enregistrement sur le dashbord Meraki dans le Cloud, j'avoue ne pas 
savoir comment à marche exactement.
Mais ils n'ont jamais été enregistrés dans notre dashboard.


Par contre, il n'y a pas de RMA possible sur du matériel revendu. C'est la 
politique générale chez Cisco :(




-
Louis


-Message d'origine-
De : Jonathan Lesciauskas | Plurium Technologies US  
Envoyé : vendredi 21 octobre 2022 15:12
À : BELLOTTO Louis 
Objet : RE: [BIZ] Matériel Cisco Meraki

[Vous ne recevez pas souvent de courriers de j...@plurium.com. Découvrez 
pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]

Bonjour Louis,

Pourrais-je avoir la liste complète?

Je suis intéressée, nous avons des opérations sur Paris ce ne serait pas un 
problème pour nous pour les récupérer.

Je presume qu'ils peuvent être unclaimed de votre dashboard s'il le sont, n;est 
ce pas?

Cordialement,

Jonathan Lesciauskas
General Manager USA


Plurium Technologies US
5085 Avalon Ridge PKWY, STE 150
Peachtree Corners, GA 30071 - USA
A member of Plurium Technologies Group
T : +1 770-417-8275
M: +1 678-333-4512
j...@plurium.com



www.plurium.com


-Original Message-
From: frnog-requ...@frnog.org  On Behalf Of BELLOTTO 
Louis
Sent: Friday, October 21, 2022 8:45 AM
To: frnog-...@frnog.org
Subject: [FRnOG] [BIZ] Matériel Cisco Meraki

Bonjour,

Il me reste pas mal de matériel Méraki *jamais* utilisé, tout neuf encore dans 
les cartons d'origine.
MS250-48LP, MS410-16, MX84, MR42 ... à récupérer sur Paris 6.

Liste détaillée/prix sur demande si vous êtez intéressés.








-
 Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce 
message non conforme à sa destination, toute diffusion, copie ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
préalable. Son contenu ne saurait constituer en aucun cas un engagement 
contractuel, une offre de souscrire à quelconque produit ou instrument 
financier ou une sollicitation à investir de la part du Groupe La Française et 
toutes opinions exprimées dans ce message ne sauraient nécessairement refléter 
celle du Groupe La Française. Le contenu de cet email peut contenir des virus 
informatiques qui pourraient endommager votre système informatique. Bien que 
Groupe La Française ait pris toutes les précautions raisonnables pour minimiser 
ce risque, nous déclinons toute responsabilité pour tout dommage que vous 
pourriez subir en raison de virus informatiques. Si vous recevez ce courriel 
par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. 
Nous vous invitons à prendre connaissance de notre politique de confidentialité 
et de cookies en cliquant ici 
https://www.la-francaise.com/fr/politique-de-confidentialite

 
-
 This message and any attachments are confidential and may be legally 
privileged or otherwise protected from disclosure. It is intended only for the 
stated addressee(s). Any use, dissemination, copy or disclosure of this message 
not in accordance with its purpose, either in whole or in part, is prohibited 
without our prior formal approval. Its contents, given solely for information, 
does not constitute a commitment or an offer to subscribe to any financial 
product by La Française Group. Any opinion expressed in this email may not 
necessarily reflect the opinion of La Française Group. The content of this 
email may contain computer viruses that could damage your computer system. 
Although La Française Group has taken all reasonable precautions to minimize 
this risk, we decline any liability for any damage you may suffer due to 
computer viruses. If you are neither the addressee nor an authorized recipient 
of this message, please notify the sender of receipt immediately and delete 
this message from your system. We invite you to read our privacy and cookies 
policy available on the Group's website by clicking here 
https://www.la-francaise.com/en/privacy-policy

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

-
 Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce 
message non conforme à sa destination, toute diffusion, copie ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
préalable. Son contenu ne saurait constituer en aucun cas un engagement 
contractuel, une offre de souscrire à quelconque produit ou instrument 
financier ou une sollicitation à investir

[FRnOG] [BIZ] Matériel Cisco Meraki

[BELLOTTO Louis]

Bonjour,

Il me reste pas mal de matériel Méraki *jamais* utilisé, tout neuf encore dans 
les cartons d'origine.
MS250-48LP, MS410-16, MX84, MR42 ... à récupérer sur Paris 6.

Liste détaillée/prix sur demande si vous êtez intéressés.








-
 Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce 
message non conforme à sa destination, toute diffusion, copie ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
préalable. Son contenu ne saurait constituer en aucun cas un engagement 
contractuel, une offre de souscrire à quelconque produit ou instrument 
financier ou une sollicitation à investir de la part du Groupe La Française et 
toutes opinions exprimées dans ce message ne sauraient nécessairement refléter 
celle du Groupe La Française. Le contenu de cet email peut contenir des virus 
informatiques qui pourraient endommager votre système informatique. Bien que 
Groupe La Française ait pris toutes les précautions raisonnables pour minimiser 
ce risque, nous déclinons toute responsabilité pour tout dommage que vous 
pourriez subir en raison de virus informatiques. Si vous recevez ce courriel 
par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. 
Nous vous invitons à prendre connaissance de notre politique de confidentialité 
et de cookies en cliquant ici 
https://www.la-francaise.com/fr/politique-de-confidentialite

 
-
 This message and any attachments are confidential and may be legally 
privileged or otherwise protected from disclosure. It is intended only for the 
stated addressee(s). Any use, dissemination, copy or disclosure of this message 
not in accordance with its purpose, either in whole or in part, is prohibited 
without our prior formal approval. Its contents, given solely for information, 
does not constitute a commitment or an offer to subscribe to any financial 
product by La Française Group. Any opinion expressed in this email may not 
necessarily reflect the opinion of La Française Group. The content of this 
email may contain computer viruses that could damage your computer system. 
Although La Française Group has taken all reasonable precautions to minimize 
this risk, we decline any liability for any damage you may suffer due to 
computer viruses. If you are neither the addressee nor an authorized recipient 
of this message, please notify the sender of receipt immediately and delete 
this message from your system. We invite you to read our privacy and cookies 
policy available on the Group's website by clicking here 
https://www.la-francaise.com/en/privacy-policy

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

[FRnOG] [JOBS] [JOBS] [JOBS] [BAYONNE][PAU] Ingénieur Avant-Vente / Chef de projet chez l'opérateur IZARLINK

[Jean Louis MELIN]

Bonjour à tous

IzarLink est un opérateur télécom de proximité en pleine croissance, membre de 
l’AOTA, qui possède son propre réseau FTTO sur les dépt 64 et 40 associé au 
Data Center de proximité IzarHost.

Nous recherchons un(e) collaborateur(trice) motivé(e) pour construire nos 
dossiers techniques de réponse aux besoins exprimés par les entreprises du Pays 
Basque et des Pays de l’Adour et cadrer les projets de réalisation.

Votre mission si vous l’acceptez :
• Assister l’équipe commerciale dans l’analyse du besoin Client
• Rédiger les mémoires techniques de nos offres
• Participer à la soutenance des offres avec notre équipe commerciale
• Cadrer le projet de réalisation
• Être l’ambassadeur de nos offres et de nos valeurs.

Ça vous ressemble ?
• Vous maitrisez techniquement les offres opérateurs de réseaux d’entreprise 
(VPN MPLS, Trunk SIP …) et les services de Cloud Privés pour entreprise (VM, 
Firewall, sauvegarde, Cloud PBX …)
• Vous savez gérer un projet
• Vous avez la culture de la satisfaction client.

Vous justifiez d’un passé dans l’exploitation d’architectures réseaux complexes 
et/ou de solutions d’hébergement et vous êtes attachés aux valeurs d’un 
opérateur local, alors rejoignez-nous !

Type de contrat : CDI à pourvoir immédiatement.
Rémunération : en fonction de l’expérience
Avantages : Mutuelle 100%, chèques déjeuners, large autonomie.

N’hésitez pas à me contacter par mail pour plus d’informations

Cordialement
Jean-Louis Mélin
jlme...@izarralde.com ou jlme...@izarlink.com


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

[FRnOG] [JOBS] [JOBS] [BAYONNE][PAU] Administrateur / Administratrice Télécoms & Réseaux chez l'opérateur IZARLINK

[Jean-Louis Mélin]

Bonjour à tous

IzarLink est un opérateur télécom de proximité en pleine croissance, membre de 
l'AOTA, qui possède son propre réseau FTTO sur les dépt 64 et 40 associé au 
Data Center de proximité IzaHost.

Dans le cadre de l'extension de notre réseau, nous recherchons un(e) 
collaborateur(trice) motivé(e) par le déploiement et la gestion d'un  réseau 
opérateur de dernière génération en Fibre Optique dédié aux entreprises (FTTO) 
du Pays Basque et des Pays de l'Adour.

Possédant une bonne maîtrise des technologies opérateurs (routage OSPF/BGP, 
infrastructures MPLS/VPLS, administration SNMP, sécurisation des réseaux, ToIP 
...) et des plateformes serveurs (Linux, VMWARE/PROXMOX) vous participez 
activement à l'extension de notre réseau et au support technique de nos Clients 
entreprises.

Vous avez une formation Bac+2 minimum dans la spécialisation Réseaux et 
Télécom, une première expérience significative dans la gestion de réseaux 
complexes et vous êtes attachés aux valeurs d'un opérateur local, alors 
rejoignez-nous !

Type de contrat : CDI à pourvoir immédiatement.
Rémunération : en fonction de l'expérience
Avantages : Mutuelle 100%, chèques déjeuners, large autonomie.

Cordialement
Jean-Louis Mélin

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

RE: [FRnOG] [TECH] Portail publication applis Http/https

[BELLOTTO Louis]

Ca ressemble beaucoup à du Citrix...


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Philippe M
Envoyé : lundi 29 novembre 2021 13:08
À : frnog-t...@frnog.org
Objet : [FRnOG] [TECH] Portail publication applis Http/https

Bonjour,

Quelqu'un a t-il des pointeurs interessants pour soft de portail de publication 
d'application pour des users nomades (pas simplement un nginx, haproxy).

J'ai un tête un portail destiné à des prestataires externes qui présenterai 
facilement quelques icones sur une page Web, puis fonctionnerai en reverse 
proxy vers des serveurs internes (applis http/https).

Contraintes:
- Soft Linux ou Windows
- Pas d'appliance ou soft Firewall plus complet sous forme de VM.
- Mieux si MFA (type google authenticator)
- Mieux si lien avec AD pour les applis publiées selon le user

Merci.
PM.

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

-
 Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce 
message non conforme à sa destination, toute diffusion, copie ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
préalable. Son contenu ne saurait constituer en aucun cas un engagement 
contractuel, une offre de souscrire à quelconque produit ou instrument 
financier ou une sollicitation à investir de la part du Groupe La Française et 
toutes opinions exprimées dans ce message ne sauraient nécessairement refléter 
celle du Groupe La Française. Le contenu de cet email peut contenir des virus 
informatiques qui pourraient endommager votre système informatique. Bien que 
Groupe La Française ait pris toutes les précautions raisonnables pour minimiser 
ce risque, nous déclinons toute responsabilité pour tout dommage que vous 
pourriez subir en raison de virus informatiques. Si vous recevez ce courriel 
par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. 
Nous vous invitons à prendre connaissance de notre politique de confidentialité 
et de cookies en cliquant ici 
https://www.la-francaise.com/fr/politique-de-confidentialite-et-de-cookies/ 
-
 This message and any attachments are confidential and may be legally 
privileged or otherwise protected from disclosure. It is intended only for the 
stated addressee(s). Any use, dissemination, copy or disclosure of this message 
not in accordance with its purpose, either in whole or in part, is prohibited 
without our prior formal approval. Its contents, given solely for information, 
does not constitute a commitment or an offer to subscribe to any financial 
product by La Française Group. Any opinion expressed in this email may not 
necessarily reflect the opinion of La Française Group. The content of this 
email may contain computer viruses that could damage your computer system. 
Although La Française Group has taken all reasonable precautions to minimize 
this risk, we decline any liability for any damage you may suffer due to 
computer viruses. If you are neither the addressee nor an authorized recipient 
of this message, please notify the sender of receipt immediately and delete 
this message from your system. We invite you to read our privacy and cookies 
policy available on the Group’s website by clicking here 
https://www.la-francaise.com/en/privacy-and-cookies-policy/ 
---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] RE: BGP et /24

[BELLOTTO Louis]

la moins bonne, c'est que j'ai 6 /27 chez plusieurs opérateurs.
sans surnetting possible.



-Message d'origine-
De : David Ponzone  
Envoyé : mardi 26 octobre 2021 15:49
À : BELLOTTO Louis 
Cc : frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] RE: BGP et /24

La bonne nouvelle, c’est que pour avoir un /24, te suffit de demander au RIPE, 
payer 2000€ de frais de dossier et 1500€/an.

> Le 26 oct. 2021 à 15:45, BELLOTTO Louis  a écrit :
> 
> OK, c'est plus clair et effectivement à l'extrème, si chacun fait du /32 ... 
> bonjour la taille des tables !
> Merci Laurent.
> 


-
 Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce 
message non conforme à sa destination, toute diffusion, copie ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
préalable. Son contenu ne saurait constituer en aucun cas un engagement 
contractuel, une offre de souscrire à quelconque produit ou instrument 
financier ou une sollicitation à investir de la part du Groupe La Française et 
toutes opinions exprimées dans ce message ne sauraient nécessairement refléter 
celle du Groupe La Française. Le contenu de cet email peut contenir des virus 
informatiques qui pourraient endommager votre système informatique. Bien que 
Groupe La Française ait pris toutes les précautions raisonnables pour minimiser 
ce risque, nous déclinons toute responsabilité pour tout dommage que vous 
pourriez subir en raison de virus informatiques. Si vous recevez ce courriel 
par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. 
Nous vous invitons à prendre connaissance de notre politique de confidentialité 
et de cookies en cliquant ici 
https://www.la-francaise.com/fr/politique-de-confidentialite-et-de-cookies/ 
-
 This message and any attachments are confidential and may be legally 
privileged or otherwise protected from disclosure. It is intended only for the 
stated addressee(s). Any use, dissemination, copy or disclosure of this message 
not in accordance with its purpose, either in whole or in part, is prohibited 
without our prior formal approval. Its contents, given solely for information, 
does not constitute a commitment or an offer to subscribe to any financial 
product by La Française Group. Any opinion expressed in this email may not 
necessarily reflect the opinion of La Française Group. The content of this 
email may contain computer viruses that could damage your computer system. 
Although La Française Group has taken all reasonable precautions to minimize 
this risk, we decline any liability for any damage you may suffer due to 
computer viruses. If you are neither the addressee nor an authorized recipient 
of this message, please notify the sender of receipt immediately and delete 
this message from your system. We invite you to read our privacy and cookies 
policy available on the Group’s website by clicking here 
https://www.la-francaise.com/en/privacy-and-cookies-policy/ 
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] RE: BGP et /24

[BELLOTTO Louis]

OK, c'est plus clair et effectivement à l'extrème, si chacun fait du /32 ... 
bonjour la taille des tables !
Merci Laurent.




-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Laurent 
Guinchard
Envoyé : mardi 26 octobre 2021 15:37
À : frnog-al...@frnog.org
Objet : [FRnOG] [ALERT] RE: BGP et /24

C'est une convention/une bonne pratique, sur Internet, les opérateurs ne 
routent pas de subnet plus petit qu'un /24.
Cela permet de ne pas faire exploser la taille de la full-view en 30sec. 
Parce que oui, un /25 ou un /27 c'est possible techniquement ... au même titre 
qu'un /32. 
Mais si on se met tous à router des /32, la taille de la table sera tellement 
grosse qu'on va casser pas mal de routeur sur Internet Il fallait donc fixer 
une limite, et c'est donc /24.

NB : la full view est passe cette semaine à 900k routes sur CIDR-report ...

Cordialement,

Laurent GUINCHARD





-Message d'origine-
De : frnog-requ...@frnog.org  De la part de BELLOTTO 
Louis Envoyé : mardi 26 octobre 2021 15:27 À : frnog-al...@frnog.org Objet : 
[FRnOG] [ALERT] BGP et /24

Hello,

Un fournisseur de service (protection ddos) qui me dit que pour pouvoir faire 
du BGP sur nos liens Internet sur plusieurs datacenter, il nous faut des 
étendues d'adresses IP en /24. J'ai un peu de mal avec cette affirmation et je 
ne vois pas pourquoi avec un /25 ou /27 ça ne serait pas possible.

Bien sûr, le /24 est le plus répendu... mais bon. Pas sûr que tout le monde 
puisse avoir et justifier de 254 adresses.

Un avis ?
Merci.




-
 Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce 
message non conforme à sa destination, toute diffusion, copie ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
préalable. Son contenu ne saurait constituer en aucun cas un engagement 
contractuel, une offre de souscrire à quelconque produit ou instrument 
financier ou une sollicitation à investir de la part du Groupe La Française et 
toutes opinions exprimées dans ce message ne sauraient nécessairement refléter 
celle du Groupe La Française. Le contenu de cet email peut contenir des virus 
informatiques qui pourraient endommager votre système informatique. Bien que 
Groupe La Française ait pris toutes les précautions raisonnables pour minimiser 
ce risque, nous déclinons toute responsabilité pour tout dommage que vous 
pourriez subir en raison de virus informatiques. Si vous recevez ce courriel 
par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. 
Nous vous invitons à prendre connaissance de notre politique de confidentialité 
et de cookies en cliquant ici 
https://www.la-francaise.com/fr/politique-de-confidentialite-et-de-cookies/ 
-
 This message and any attachments are confidential and may be legally 
privileged or otherwise protected from disclosure. It is intended only for the 
stated addressee(s). Any use, dissemination, copy or disclosure of this message 
not in accordance with its purpose, either in whole or in part, is prohibited 
without our prior formal approval. Its contents, given solely for information, 
does not constitute a commitment or an offer to subscribe to any financial 
product by La Française Group. Any opinion expressed in this email may not 
necessarily reflect the opinion of La Française Group. The content of this 
email may contain computer viruses that could damage your computer system. 
Although La Française Group has taken all reasonable precautions to minimize 
this risk, we decline any liability for any damage you may suffer due to 
computer viruses. If you are neither the addressee nor an authorized recipient 
of this message, please notify the sender of receipt immediately and delete 
this message from your system. We invite you to read our privacy and cookies 
policy available on the Group’s website by clicking here 
https://www.la-francaise.com/en/privacy-and-cookies-policy/
---
Liste de diffusion du FRnOG
http://www.frnog.org/

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

-
 Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce 
message non conforme à sa destination, toute diffusion, copie ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
préalable. Son contenu ne saurait constituer en aucun cas un engagement 
contractuel, une offre de souscrire à quelconque produit ou instrument 
financier ou une sollicitation à investir de la part du

RE: [FRnOG] [TECH] BGP et /24

[BELLOTTO Louis]

sorry pour l'urgent.
je me suis trompé 

-Message d'origine-
De : David Ponzone  
Envoyé : mardi 26 octobre 2021 15:29
À : BELLOTTO Louis 
Cc : frnog-tech 
Objet : Re: [FRnOG] [TECH] BGP et /24

(Reclassé en TECH, je vois pas l’’urgence)


-
 Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce 
message non conforme à sa destination, toute diffusion, copie ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
préalable. Son contenu ne saurait constituer en aucun cas un engagement 
contractuel, une offre de souscrire à quelconque produit ou instrument 
financier ou une sollicitation à investir de la part du Groupe La Française et 
toutes opinions exprimées dans ce message ne sauraient nécessairement refléter 
celle du Groupe La Française. Le contenu de cet email peut contenir des virus 
informatiques qui pourraient endommager votre système informatique. Bien que 
Groupe La Française ait pris toutes les précautions raisonnables pour minimiser 
ce risque, nous déclinons toute responsabilité pour tout dommage que vous 
pourriez subir en raison de virus informatiques. Si vous recevez ce courriel 
par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. 
Nous vous invitons à prendre connaissance de notre politique de confidentialité 
et de cookies en cliquant ici 
https://www.la-francaise.com/fr/politique-de-confidentialite-et-de-cookies/ 
-
 This message and any attachments are confidential and may be legally 
privileged or otherwise protected from disclosure. It is intended only for the 
stated addressee(s). Any use, dissemination, copy or disclosure of this message 
not in accordance with its purpose, either in whole or in part, is prohibited 
without our prior formal approval. Its contents, given solely for information, 
does not constitute a commitment or an offer to subscribe to any financial 
product by La Française Group. Any opinion expressed in this email may not 
necessarily reflect the opinion of La Française Group. The content of this 
email may contain computer viruses that could damage your computer system. 
Although La Française Group has taken all reasonable precautions to minimize 
this risk, we decline any liability for any damage you may suffer due to 
computer viruses. If you are neither the addressee nor an authorized recipient 
of this message, please notify the sender of receipt immediately and delete 
this message from your system. We invite you to read our privacy and cookies 
policy available on the Group’s website by clicking here 
https://www.la-francaise.com/en/privacy-and-cookies-policy/ 
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [ALERT] BGP et /24

[BELLOTTO Louis]

Hello,

Un fournisseur de service (protection ddos) qui me dit que pour pouvoir faire 
du BGP sur nos liens Internet sur plusieurs datacenter, il nous faut des 
étendues d'adresses IP en /24. J'ai un peu de mal avec cette affirmation et je 
ne vois pas pourquoi avec un /25 ou /27 ça ne serait pas possible.

Bien sûr, le /24 est le plus répendu... mais bon. Pas sûr que tout le monde 
puisse avoir et justifier de 254 adresses.

Un avis ?
Merci.




-
 Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce 
message non conforme à sa destination, toute diffusion, copie ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
préalable. Son contenu ne saurait constituer en aucun cas un engagement 
contractuel, une offre de souscrire à quelconque produit ou instrument 
financier ou une sollicitation à investir de la part du Groupe La Française et 
toutes opinions exprimées dans ce message ne sauraient nécessairement refléter 
celle du Groupe La Française. Le contenu de cet email peut contenir des virus 
informatiques qui pourraient endommager votre système informatique. Bien que 
Groupe La Française ait pris toutes les précautions raisonnables pour minimiser 
ce risque, nous déclinons toute responsabilité pour tout dommage que vous 
pourriez subir en raison de virus informatiques. Si vous recevez ce courriel 
par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. 
Nous vous invitons à prendre connaissance de notre politique de confidentialité 
et de cookies en cliquant ici 
https://www.la-francaise.com/fr/politique-de-confidentialite-et-de-cookies/ 
-
 This message and any attachments are confidential and may be legally 
privileged or otherwise protected from disclosure. It is intended only for the 
stated addressee(s). Any use, dissemination, copy or disclosure of this message 
not in accordance with its purpose, either in whole or in part, is prohibited 
without our prior formal approval. Its contents, given solely for information, 
does not constitute a commitment or an offer to subscribe to any financial 
product by La Française Group. Any opinion expressed in this email may not 
necessarily reflect the opinion of La Française Group. The content of this 
email may contain computer viruses that could damage your computer system. 
Although La Française Group has taken all reasonable precautions to minimize 
this risk, we decline any liability for any damage you may suffer due to 
computer viruses. If you are neither the addressee nor an authorized recipient 
of this message, please notify the sender of receipt immediately and delete 
this message from your system. We invite you to read our privacy and cookies 
policy available on the Group’s website by clicking here 
https://www.la-francaise.com/en/privacy-and-cookies-policy/ 
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Client IPsec Linux

[Louis]

j'avais mal lu. Ce n'est pas une solution client mais de concentrateur. Le
client à utiliser et celui natif de windows et ceux présents avec les
distribs linux.

Le jeu. 1 avr. 2021 à 18:25, David Ponzone  a
écrit :

> Tu l’as déployé en client ?
> Parce que bon, c’est plutôt une solution pour faire un concentrateur IPsec.
> C’est pas forcément simple à déployer sur un laptop Linux.
> Et c’est commercial.
>
> Ceci dit, +1, 6wind, ça déchire!
>
> > Le 1 avr. 2021 à 18:18, Louis  a écrit :
> >
> > Hello,
> >
> > IPsec nomade avec de la perf.
> > https://www.6wind.com/vrouter-solutions/turbo-ipsec/
> >
> > Basé sur ubuntu mais avec une stack réseau améliorée.
> >
>
>
>

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

Re: [FRnOG] [TECH] Client IPsec Linux

[Louis]

Hello,

IPsec nomade avec de la perf.
https://www.6wind.com/vrouter-solutions/turbo-ipsec/

Basé sur ubuntu mais avec une stack réseau améliorée.

Le jeu. 1 avr. 2021 à 17:48, Hugo SIMANCAS 
a écrit :

> c'est galère à configurer non ?
>
> de mémoire c'est pas simple en mode nomade isakmp sans ipfixe du nomade ?
>
> Merci
>
>
>
> / ::1  Hugo SIMANCAS
> Directeur Technique Associé
> https://www.data-expertise.com [https://www.data-expertise.com/]
> Support technique : 09 78 23 20 29
> Standard : 05 34 26 02 46 | Ligne directe : 05 34 26 50 57
> Mobile : 06 95 44 29 64
> !Utilisez notre plateforme visio libre & gratuite :
> https://conf.data-expertise.com/ [https://conf.data-expertise.com/]
> !Pad collaboratif libre & gratuit sécurisé https://pad.data-expertise.com/
> [https://pad.data-expertise.com/]
>
> Les informations contenues dans ce courrier électronique sont
> confidentielles et protégées par le secret professionnel. En tout état de
> cause, elles ne sont destinées qu'à la personne ou entreprise dont le nom
> est mentionné ci-dessus. Veuillez aviser l'expéditeur de toute difficulté
> ou de toute erreur dans la transmission de ce document. Si vous n'êtes pas
> le destinataire du présent courrier, vous n'êtes pas autorisé, sous peine
> de poursuites à en prendre des copies, le divulguer ou le diffuser. La
> présence de cette note prouve également que ce message électronique a été
> vérifié par un logiciel anti-virus.
>
>
>
> Le 01/04/2021 à 17:31, Vincent Habchi a écrit :
> > Hello,
> >
> > (Au risque de dire une connerie) Perso j’utilise Strongswan avec mes
> clients nomades et je n’ai eu de problèmes de perf.
> >
> > Ça fonctionne même avec Windows.
> >
> > V.
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> >
> https://antiphishing.vadesecure.com/1/aHVnby5zaW1hbmNhc0BkYXRhLWV4cGVydGlzZS5jb218VlJDNDc0NjUz/www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

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

[Louis Poinsignon]

On a mis à jour Cloudflare status: pour suivre l'incident en cours
https://www.cloudflarestatus.com/incidents/t2vcfxt28rwn

On Wed, Jan 13, 2021 at 8:54 AM Jérôme Fleury  wrote:

> Merci pour le signalement. C'est en cours d'investigation chez Cloudflare.
>
> En ce qui concerne l'annonce sur les RS, je confirme que Cloudflare
> n'annonce pas 1.1.1.0/24 et 1.0.0.0/24 sur les route-servers de FranceIX
> (et aucun route-server en general)
>
> On Wed, Jan 13, 2021 at 5:48 PM Clement Cavadore 
> wrote:
>
> > Message passé à qui de droit pour 1.1.1.1, tant coté Cloudflare, que
> > OTI. (Nb: 1.0.0.1 fonctionne depuis OTI)
> >
> > Le mercredi 13 janvier 2021 à 17:30 +0100, Romain a écrit :
> > > Si, ça dépend comment tu tests. Ca a été corrigé via le firmware il y
> > > a
> > > longtemps, même si un traceroute par défaut le route en local sur la
> > > livebox.
> > > Un traceroute en UDP sur le port 53 montre bien un routage correct
> > > vers
> > > l'extérieur.
> > >
> > > Le mer. 13 janv. 2021 à 17:17, Paul Caranton  > > > a
> > > écrit :
> > >
> > > > 1.1.1.1 ne fonctionne pas derrière une Livebox (pas la 4 en tout
> > > > cas).
> > > >
> > > > Paul
> > > > AS208261
> > > >
> > > > Le 13 janv. 2021 à 17:16, à 17:16, Raphael Mazelier <
> > > > r...@futomaki.net> a
> > > > écrit:
> > > > > Je ne sais pas mais chez moi (cnx orange) 1.1.1.1 était pétave
> > > > > aussi.
> > > > >
> > > > > On 13/01/2021 17:03, David Ponzone wrote:
> > > > > > Ami.e.s France-IXien.ne.s,
> > > > > >
> > > > > > Est-ce normal que Cloudflare n’annonce pas le 1.1.1.0/24 aux RS
> > > > > > de
> > > > > France-IX ?
> > > > > > Merci
> > > > > >
> > > > > >
> > > > > > ---
> > > > > > Liste de diffusion du FRnOG
> > > > > > http://www.frnog.org/
> > > > >
> > > > > ---
> > > > > Liste de diffusion du FRnOG
> > > > > http://www.frnog.org/
> > > >
> > > > ---
> > > > Liste de diffusion du FRnOG
> > > > http://www.frnog.org/
> > > >
> > >
> > > ---
> > > Liste de diffusion du FRnOG
> > > http://www.frnog.org/
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

RE: [FRnOG] [TECH] lien de transit SFR

[BELLOTTO Louis]

un petit outil pourfaire les tests facilement :
http://www.elifulkerson.com/projects/mturoute.php


--
Louis


-Message d'origine-
De : David Ponzone  
Envoyé : vendredi 18 décembre 2020 14:56
À : Nicolas Parpandet 
Cc : BELLOTTO Louis ; frnog-tech 

Objet : Re: [FRnOG] [TECH] lien de transit SFR

Attention y a des ping qui attendent en argument la taille du paquet headers 
inclus, et d’autre la taille du payload.
Généralement ça affiche size_payload(size_withheaders) avant de commencer le 
ping.

Ceci dit, pour être sûr sûr que tout est ok, ajoute le bit DF.
Si ça passe à 1472(1500) avec DF, et que ça passe plus avec 1473(1501), tout va 
bien.
Sinon problème.

> Le 18 déc. 2020 à 14:41, Nicolas Parpandet  a écrit :
> 
> 
> Bonjour,
> 
> Ok bonne idée pour le mtu,
> j'ai le ping qui monte à 1472, donc c'est OK à priori... (+20 IP + 8 
> ICMP = 1500)
> 
> 
> Merci
> 
> Nicolas
> 
> ----- Mail original -
>> De: "BELLOTTO Louis" 
>> À: "frnog-tech" 
>> Envoyé: Vendredi 18 Décembre 2020 14:09:50
>> Objet: RE: [FRnOG] [TECH] lien de transit SFR
> 
>> Bonjour,
>> 
>> On a eu aussi un truc du même genre.
>> Le souci venait du réglage du MTU sur un des routeurs opérateur...
>> 
>> Point peut être à vérifier
>> 
>> 
>> --
>> Louis
>> 
>> 
>> 
>> -Message d'origine-
>> De : frnog-requ...@frnog.org  De la part de 
>> Thierry Chich Envoyé : vendredi 18 décembre 2020 13:54 À : 'Olivier 
>> Tirat BYON' ; 'Nicolas Parpandet'
>> ; 'frnog-tech'  Objet : RE: 
>> [FRnOG] [TECH] lien de transit SFR
>> 
>> Bonjour
>> 
>> C'est vrai que j'aurais pensé à priori à un shaping. Bien sûr, il 
>> peut aussi y avoir des soucis liés à la latence sur le lien qui peut 
>> diminuer fortement le débit atteignable en tcp.
>> J'ai déjà eu aussi des effets particulièrement forts de l'interaction 
>> entre politique de firewalling et offloading des cartes réseaux. Le 
>> débit passait de 70Mo/s à 250 Mo/s en désactivant l'offloading ( 
>> ethtool -K ens192 tso off) sur certaines version de redhat.
>> 
>> Tout ça pour dire que ce genre de constat dépend parfois de 
>> paramètres très complexes à identifier
>> 
>> Thierry CHICH
>> 
>> -Message d'origine-
>> De : frnog-requ...@frnog.org  De la part de 
>> Olivier Tirat BYON Envoyé : vendredi 18 décembre 2020 12:25 À : 
>> Nicolas Parpandet ; frnog-tech  
>> Objet : Re: [FRnOG] [TECH] lien de transit SFR
>> 
>> Bonjour
>> 
>> Bon différence majeur entre udp et tcp... l'aquittement des paquets
>> (TCP ACK).
>> 
>> On peut tester un upload indépendament du download ent UDP mais pas 
>> du tout en TCP.
>> 
>> Il faut faire gaffe au debit en download, s'assurer qu'il y a la 
>> place dans le tuyau pour les paquets TCP ACK. Et bien geré la fenêtre 
>> pour eviter les TCP RETRANSMIT
>> 
>> Si en fait ton lien passe les 850 Mbit/s en udp  c'est que le niveau 
>> peut atteindre ces performances indépendamment. Donc le problème en 
>> TCP ne doit pas venir du lien. Après tester des performances réelles 
>> d'un transit c'est pas facile car ca dépend aussi de l'autre 
>> extrémité;)
>> 
>> Le 18/12/2020 à 11:52, Nicolas Parpandet a écrit :
>>> 
>>> Bonjour,
>>> 
>>> Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte 
>>> bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si 
>>> il y avait une QOS quelque part sur les sessions TCP, (le chiffre de 
>>> 100Mbits/s revient tellement souvent dans nos tests, la probabilité 
>>> que cela soit lié au hasard me semble faible...)
>>> 
>>> De plus, avec une dizaine de sessions tcp en // , le débit global 
>>> plafonne à 350Mbits...
>>> 
>>> Cela fait plusieurs semaines que nous échangeons dans tous les sens 
>>> avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le 
>>> problème, et cela n'avance pas !
>>> 
>>> est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de 
>>> limite avec cet opérateur ?, nous avons fait énormément de contrôles 
>>> de notre côté, il me semble que c'est bien en face le soucis ..., il 
>>> peut toujours subsister un doute, mais si quelqu'un à une expérience sur le 
>>> sujet !
>>> 
>>> Merci, A+
>>> 
>>> Nicolas
>>> 
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>> 
&g

RE: [FRnOG] [TECH] lien de transit SFR

[BELLOTTO Louis]

Bonjour,

On a eu aussi un truc du même genre.
Le souci venait du réglage du MTU sur un des routeurs opérateur...

Point peut être à vérifier


--
Louis



-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Thierry 
Chich
Envoyé : vendredi 18 décembre 2020 13:54
À : 'Olivier Tirat BYON' ; 'Nicolas Parpandet' 
; 'frnog-tech' 
Objet : RE: [FRnOG] [TECH] lien de transit SFR

Bonjour

C'est vrai que j'aurais pensé à priori à un shaping. Bien sûr, il peut aussi y 
avoir des soucis liés à la latence sur le lien qui peut diminuer fortement le 
débit atteignable en tcp. 
J'ai déjà eu aussi des effets particulièrement forts de l'interaction entre 
politique de firewalling et offloading des cartes réseaux. Le débit passait de  
70Mo/s à 250 Mo/s en désactivant l'offloading ( ethtool -K ens192 tso off) sur 
certaines version de redhat.

Tout ça pour dire que ce genre de constat dépend parfois de paramètres très 
complexes à identifier

Thierry CHICH

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Olivier 
Tirat BYON Envoyé : vendredi 18 décembre 2020 12:25 À : Nicolas Parpandet 
; frnog-tech  Objet : Re: [FRnOG] [TECH] 
lien de transit SFR

Bonjour

Bon différence majeur entre udp et tcp... l'aquittement des paquets
(TCP ACK).

On peut tester un upload indépendament du download ent UDP mais pas du tout en 
TCP.

Il faut faire gaffe au debit en download, s'assurer qu'il y a la place dans le 
tuyau pour les paquets TCP ACK. Et bien geré la fenêtre pour eviter les TCP 
RETRANSMIT

Si en fait ton lien passe les 850 Mbit/s en udp  c'est que le niveau peut 
atteindre ces performances indépendamment. Donc le problème en TCP ne doit pas 
venir du lien. Après tester des performances réelles d'un transit c'est pas 
facile car ca dépend aussi de l'autre extrémité;)

Le 18/12/2020 à 11:52, Nicolas Parpandet a écrit :
>
> Bonjour,
>
> Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte 
> bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si 
> il y avait une QOS quelque part sur les sessions TCP, (le chiffre de 
> 100Mbits/s revient tellement souvent dans nos tests, la probabilité 
> que cela soit lié au hasard me semble faible...)
>
> De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à 
> 350Mbits...
>
> Cela fait plusieurs semaines que nous échangeons dans tous les sens 
> avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le problème, 
> et cela n'avance pas !
>
> est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de 
> limite avec cet opérateur ?, nous avons fait énormément de contrôles 
> de notre côté, il me semble que c'est bien en face le soucis ..., il peut 
> toujours subsister un doute, mais si quelqu'un à une expérience sur le sujet !
>
> Merci, A+
>
> Nicolas
>
>
>
> ---
> 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/

-
 Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce 
message non conforme à sa destination, toute diffusion, copie ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
préalable. Son contenu ne saurait constituer en aucun cas un engagement 
contractuel, une offre de souscrire à quelconque produit ou instrument 
financier ou une sollicitation à investir de la part du Groupe La Française et 
toutes opinions exprimées dans ce message ne sauraient nécessairement refléter 
celle du Groupe La Française. Le contenu de cet email peut contenir des virus 
informatiques qui pourraient endommager votre système informatique. Bien que 
Groupe La Française ait pris toutes les précautions raisonnables pour minimiser 
ce risque, nous déclinons toute responsabilité pour tout dommage que vous 
pourriez subir en raison de virus informatiques. Si vous recevez ce courriel 
par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. 
Nous vous invitons à prendre connaissance de notre politique de confidentialité 
et de cookies en cliquant ici 
https://www.la-francaise.com/fr/politique-de-confidentialite-et-de-cookies/ 
-
 This message and any attachments are confidential and may be legally 
privileged or otherwise protected from disclosure. It is intended only for the 
stated addressee(s). Any use, dissemination, copy or disclosure of this message 
not in accordance with its purpose, either in whole or in part, is prohibited 
without our prior form

Re: [MISC] Re: [FRnOG] Accès compte HS

[Louis]

c'est juste mais je pense que c'est dû au fait certaines applications
utilisent les API internes au téléphone Google non au fait d'être rooté.
Marcherait avec un téléphone rooté sous android classique.

Le ven. 7 août 2020 à 14:06, Jérôme Nicolle  a écrit :

> Louis,
>
> Le 07/08/2020 à 13:56, Louis a écrit :
> > pas sûr qu'une application sache détecter ça
>
> Si si, ils peuvent. Et ils le font.
>
> Du coup, impossible d'utiliser une néobanque sans être soumis à Google
> ou Apple.
>
> Toutes les applis que j'ai pu tester refusent de tourner sur mon
> LineageOS dégooglisé, même avec MicroG. C'est totalement débile et
> toxique pour la sécurité de leurs clients, mais c'est comme ça.
>
> @+
>
> --
> Jérôme Nicolle
> +33 6 19 31 27 14
>

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

Re: [MISC] Re: [FRnOG] Accès compte HS

[Louis]

Vous avez des listes d'IPs de noeuds TOR ?

> pas de smartphone rooté / ROM alternative

pas sûr qu'une application sache détecter ça. Je me trompe ? Quand bien
même, comme pour un site web, les contrôles de sécu doivent se faire côté
serveur et non client.

Le ven. 7 août 2020 à 13:41, Jérôme Nicolle  a écrit :

> Thomas,
>
> Le 07/08/2020 à 13:27, Thomas a écrit :
> > J'ai pas compris ?
>
> Vu ta réputation, c'était une réponse attendue. Mais je réponds quand
> même pour les autres.
>
> KYC = Know Your Customer = lutte anti-blanchiment = les banques doivent
> savoir qui utilise leurs services.
>
> TOR = impossible pour elle de loguer une adresse pouvant servir à
> localiser la source en cas de poursuites judiciaires = elle bloque.
>
> Je pense que c'est un excès de zèle, mais c'est comme ça… Pas de TOR,
> pas de smartphone rooté / ROM alternative, dès qu'il s'agit de manipuler
> du pognon, la loi donne aux banques le droit d'être paranos et intrusives.
>
> @+
>
> --
> Jérôme Nicolle
> +33 6 19 31 27 14
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

RE: [FRnOG] [ALERT] Perte chez Orange / OTI

[BELLOTTO Louis]

Mêmes soucis vers 10:59
Host
Loss%   Snt   Last   Avg  Best  
Wrst StDev
 1. 192.168.1.1 
  0.0%   2660.6   0.6   0.4   
1.6   0.0
 2. 80.10.235.165   
  0.0%   2662.3   2.3   2.0   
3.5   0.1
 3. 193.249.212.114 
  0.0%   2652.3   3.1   1.7  
32.8   2.9
 4. ae43-0.nridf202.Paris15eArrondissement.francetelecom.net
  0.0%   265   18.1   3.4   2.4  
26.5   3.0
 5. ae43-0.noidf002.Aubervilliers.francetelecom.net 
  0.0%   265   19.7   4.1   2.3  
42.4   4.7
 6. 193.253.13.101  
 21.5%   265  101.9 101.6 100.3 
125.3   2.4
 7. xe-11-2-0.ter1.ncp1.par.core.as8218.eu  
 17.4%   265  101.1 101.3 100.3 
121.7   1.9
 8. gie-ufg-gw2.ter1.ncp1.par.cust.as8218.eu
 15.2%   265  107.7 106.9 101.7 
209.5   7.7
 9. 83.167.61.14.static.not.updated.neotelecoms.com 
 21.6%   265  102.0 101.8 101.4 
103.6   0.1

Le 193.253.13.101 vraiment mal.

La ça semble OK
Host
Loss%   Snt   Last   Avg  Best  
Wrst StDev
 1. AS???   192.168.1.1 
  0.0%340.7   0.7   0.6   
0.9   0.0
 2. AS???   80.10.235.165   
  0.0%342.4   2.3   2.2   
2.7   0.0
 3. AS???   193.249.212.114 
  0.0%342.4   2.8   2.0  
14.8   2.1
 4. AS???   ae43-0.nridf202.Paris15eArrondissement.francetelecom.net
  0.0%342.6   3.1   2.4   
7.0   1.0
 5. AS???   ae43-0.noidf002.Aubervilliers.francetelecom.net 
  0.0%349.7   4.9   2.6  
32.0   6.1
 6. ??? 


 7. AS8218  xe-11-2-0.ter1.ncp1.par.core.as8218.eu  
  0.0%343.2   4.1   2.9  
27.2   4.2
 8. AS8218  gie-ufg-gw2.ter1.ncp1.par.cust.as8218.eu
  0.0%349.9   9.8   4.2  
16.0   1.8
 9. AS8218  83.167.61.14.static.not.updated.neotelecoms.com 
  0.0%333.8   3.9   3.6   
7.1   0.6

Le saut 6 est toujours bizarre mai plus aucune perte.
Je peux de nouveau bosser :)




-Message d'origine-
De : frnog-requ...@frnog.org  De la part de David 
Ponzone
Envoyé : lundi 22 juin 2020 12:37
À : Quentin Leconte 
Cc : Raphael Mazelier ; frnog 
Objet : Re: [FRnOG] [ALERT] Perte chez Orange / OTI

J’ai des raisons de penser qu’il y a eu un impact aussi pour OVH, qqun a 
remarqué ?

> Le 22 juin 2020 à 12:34, Quentin Leconte  a écrit :
> 
> Pareil ici, ça semble stabilisé.
> 
> --
> 
> Quentin Leconte
> 
> Le 22/06/2020 12:33, « David Ponzone »  david.ponz...@gmail.com> a écrit :
> 
>Ca va mieux là déjà.
> 
>> Le 22 juin 2020 à 12:31, Raphael Mazelier  a écrit :
>> 
>> 
>> On 22/06/2020 12:24, Johann wrote:
>>> Hello,
>>> 
>>> On a effectivement une grosse saturation entre Zayo et Orange, cela 
>>> semble être dû à un port down + l'arrêt des annonces de Orange sur HOPUS.
>> 
>> Ouch. Ça doit faire un poil trop de report de trafic :/
>> 
>> --
>> 
>> Raphael Mazelier
>> 
>> 
>> ---
>> 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/

-
 Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
l'attention exclusive de son ou ses destinataire(s). Toute 

Re: [FRnOG] [BIZ] Devis Observium

[Louis]

Tu as trois options de mise à jour sur librenms :

   - daily : mise à jour quotidienne depuis la branche master du git
   - release : mise à jour mensuelle
   - manuel : quand on veut à partir d'une release

Par défaut, on est daily. Ce qui fait que beaucoup de gens testent le code
avant qu'une release mensuelle ne sorte. Par conséquent, le mode release /
manuel est assez sûr.

Nous avons choisi le mode manuel. Nous faisons des upgrades scriptés avec
dump de la base de données. Si besoin de retour arrière, on peut soit
restaurer la base et la version (git reset --hard VERSION) ou faire un
rollback (php artisan migrate:rollback --step=X &&  git reset --hard
VERSION - X étant le nombre de màj de la base de donnée à rollbacker)

Le mer. 8 avr. 2020 à 16:38, Kevin CHAILLY | Service Technique <
kchai...@adeo-informatique.com> a écrit :

> Au vu du fait que les intégrations sont réalisées « rapidement » et que le
> logiciel a un cycle de vie « vivant », cela ne se fait pas au détriment de
> la stabilité de celui-ci et de ses fonctionnalités ?
>
>
>
> *De :* Louis 
> *Envoyé :* mercredi 8 avril 2020 16:27
> *À :* Kevin CHAILLY | Service Technique 
> *Cc :* oups...@oupsman.fr; Radu-Adrian Feurdean <
> fr...@radu-adrian.feurdean.net>; Liste FRnoG 
> *Objet :* Re: [FRnOG] [BIZ] Devis Observium
>
>
>
> Je ne sais pas ce que tu entends par retour de flamme.
>
>
>
> J'ai pu réaliser 30 PR. Les discussions étaient constructives. Pas de
> refus. Il faut relancer quelquefois pour que le patch soit relu mais on
> peut l'utiliser en attendant qu'il soit publié dans la branche master /
> release mensuelle.
>
>
>
> Le mer. 8 avr. 2020 à 14:03, Kevin CHAILLY | Service Technique <
> kchai...@adeo-informatique.com> a écrit :
>
> Je rebondis sur ta remarque,
>
> Le support est aussi une forme d'assurance ( c'est pas moi faute c'est le
> support de XXX qui ne répond pas )
>
> Dans le cas de Librenms, le merge des PR ne provoque pas des retours de
> flamme intempestifs ?
>
> Kévin
>
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de Louis
> Envoyé : mercredi 8 avril 2020 12:26
> À : oups...@oupsman.fr
> Cc : Radu-Adrian Feurdean ; Liste FRnoG <
> frnog@frnog.org>
> Objet : Re: [FRnOG] [BIZ] Devis Observium
>
> sauf que dans les faits, le support n'est jamais réactif. On a intérêt à
> bien connaître le produit pour se dépanner soi-même.
>
> Avec librenms, on peut résoudre soi-même ses problèmes du moment qu'on
> sait lire / corriger du code. La communauté est assez flexible sur les
> merge de PR, contrairement à d'autres projets opensource. Pas besoin
> d'attendre plusieurs mois une hypothétique sortie de patch/ajout de
> fonctionnalité.
>
> Le mer. 8 avr. 2020 à 11:43,  a écrit :
>
> > D'expérience, le principal inconvénient de l'opensource c'est souvent
> > l'absence de support.
> >
> > Donc nous à JOB, on pousse du Redhat en production et du CentosOS en
> > non production. Pour avoir du support.
> >
> > On pousse du postgres en passant par un intégrateur spécialiste, pour
> > cette même problématique de support.
> >
> > Perso, si je suis appelé à 3h du matin, j'aime bien avoir un support
> > joignable dans l'heure pour me dépanner.
> >
> > -Message d'origine-
> > De : frnog-requ...@frnog.org  De la part de
> > Radu-Adrian Feurdean Envoyé : mercredi 8 avril 2020 11:33 À :
> > frnog@frnog.org Objet : Re: [FRnOG] [BIZ] Devis Observium
> >
> > On Wed, Apr 8, 2020, at 11:01, Cécile MARTRON via frnog wrote:
> > > Pour eux : open source = non fiable et non sécure.
> >
> > Fais un compte du nombre de serveurs qui tournent sous Linux, essaye
> > d'avoir une estimation des prix des licences pour tous les re-deployer
> > en windows server (one-shot, plus support annuel), essaye d'ajouter
> > des licences pour les autres composants (hors OS) qui sont a remplacer
> > par du non-open-source.
> > 1. Retiens ce chiffre, soit prete de le sortir a tout moment 2. Lance
> > le projet de "fiabilisation"/"securisation". N'hesite pas d'utiliser
> > leurs propres arguments pour pousser le projet, et minimise le cout
> > financier. La mauvaise foi est dans ce cas essentielle.
> > 2.1 Si le projet est accepte, cherche ailleurs, et vite :) 3. Le
> > projet devra en toute logique etre refuse, n'hesite pas a repliquer de
> > facon systematique avec le cout du projet si jamais on te ressort cette
> connerie.
> >
> > Certes les choses ne vont pas etre si simples, mais si jamais tu
> > t'ennuies, ca vaut la peine d'essayer cet exercice. Peut-etre ca va
> > finir avec une presentation (?? FrNOG ou similaire ??) sur l'interet
> > de l'opensource en entreprise.
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

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

Re: [FRnOG] [BIZ] Devis Observium

[Louis]

Je ne sais pas ce que tu entends par retour de flamme.

J'ai pu réaliser 30 PR. Les discussions étaient constructives. Pas de
refus. Il faut relancer quelquefois pour que le patch soit relu mais on
peut l'utiliser en attendant qu'il soit publié dans la branche master /
release mensuelle.

Le mer. 8 avr. 2020 à 14:03, Kevin CHAILLY | Service Technique <
kchai...@adeo-informatique.com> a écrit :

> Je rebondis sur ta remarque,
>
> Le support est aussi une forme d'assurance ( c'est pas moi faute c'est le
> support de XXX qui ne répond pas )
>
> Dans le cas de Librenms, le merge des PR ne provoque pas des retours de
> flamme intempestifs ?
>
> Kévin
>
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de Louis
> Envoyé : mercredi 8 avril 2020 12:26
> À : oups...@oupsman.fr
> Cc : Radu-Adrian Feurdean ; Liste FRnoG <
> frnog@frnog.org>
> Objet : Re: [FRnOG] [BIZ] Devis Observium
>
> sauf que dans les faits, le support n'est jamais réactif. On a intérêt à
> bien connaître le produit pour se dépanner soi-même.
>
> Avec librenms, on peut résoudre soi-même ses problèmes du moment qu'on
> sait lire / corriger du code. La communauté est assez flexible sur les
> merge de PR, contrairement à d'autres projets opensource. Pas besoin
> d'attendre plusieurs mois une hypothétique sortie de patch/ajout de
> fonctionnalité.
>
> Le mer. 8 avr. 2020 à 11:43,  a écrit :
>
> > D'expérience, le principal inconvénient de l'opensource c'est souvent
> > l'absence de support.
> >
> > Donc nous à JOB, on pousse du Redhat en production et du CentosOS en
> > non production. Pour avoir du support.
> >
> > On pousse du postgres en passant par un intégrateur spécialiste, pour
> > cette même problématique de support.
> >
> > Perso, si je suis appelé à 3h du matin, j'aime bien avoir un support
> > joignable dans l'heure pour me dépanner.
> >
> > -Message d'origine-
> > De : frnog-requ...@frnog.org  De la part de
> > Radu-Adrian Feurdean Envoyé : mercredi 8 avril 2020 11:33 À :
> > frnog@frnog.org Objet : Re: [FRnOG] [BIZ] Devis Observium
> >
> > On Wed, Apr 8, 2020, at 11:01, Cécile MARTRON via frnog wrote:
> > > Pour eux : open source = non fiable et non sécure.
> >
> > Fais un compte du nombre de serveurs qui tournent sous Linux, essaye
> > d'avoir une estimation des prix des licences pour tous les re-deployer
> > en windows server (one-shot, plus support annuel), essaye d'ajouter
> > des licences pour les autres composants (hors OS) qui sont a remplacer
> > par du non-open-source.
> > 1. Retiens ce chiffre, soit prete de le sortir a tout moment 2. Lance
> > le projet de "fiabilisation"/"securisation". N'hesite pas d'utiliser
> > leurs propres arguments pour pousser le projet, et minimise le cout
> > financier. La mauvaise foi est dans ce cas essentielle.
> > 2.1 Si le projet est accepte, cherche ailleurs, et vite :) 3. Le
> > projet devra en toute logique etre refuse, n'hesite pas a repliquer de
> > facon systematique avec le cout du projet si jamais on te ressort cette
> connerie.
> >
> > Certes les choses ne vont pas etre si simples, mais si jamais tu
> > t'ennuies, ca vaut la peine d'essayer cet exercice. Peut-etre ca va
> > finir avec une presentation (?? FrNOG ou similaire ??) sur l'interet
> > de l'opensource en entreprise.
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [BIZ] Devis Observium

[Louis]

sauf que dans les faits, le support n'est jamais réactif. On a intérêt à
bien connaître le produit pour se dépanner soi-même.

Avec librenms, on peut résoudre soi-même ses problèmes du moment qu'on sait
lire / corriger du code. La communauté est assez flexible sur les merge de
PR, contrairement à d'autres projets opensource. Pas besoin d'attendre
plusieurs mois une hypothétique sortie de patch/ajout de fonctionnalité.

Le mer. 8 avr. 2020 à 11:43,  a écrit :

> D'expérience, le principal inconvénient de l'opensource c'est souvent
> l'absence de support.
>
> Donc nous à JOB, on pousse du Redhat en production et du CentosOS en non
> production. Pour avoir du support.
>
> On pousse du postgres en passant par un intégrateur spécialiste, pour
> cette même problématique de support.
>
> Perso, si je suis appelé à 3h du matin, j'aime bien avoir un support
> joignable dans l'heure pour me dépanner.
>
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Radu-Adrian Feurdean
> Envoyé : mercredi 8 avril 2020 11:33
> À : frnog@frnog.org
> Objet : Re: [FRnOG] [BIZ] Devis Observium
>
> On Wed, Apr 8, 2020, at 11:01, Cécile MARTRON via frnog wrote:
> > Pour eux : open source = non fiable et non sécure.
>
> Fais un compte du nombre de serveurs qui tournent sous Linux, essaye
> d'avoir une estimation des prix des licences pour tous les re-deployer en
> windows server (one-shot, plus support annuel), essaye d'ajouter des
> licences pour les autres composants (hors OS) qui sont a remplacer par du
> non-open-source.
> 1. Retiens ce chiffre, soit prete de le sortir a tout moment 2. Lance le
> projet de "fiabilisation"/"securisation". N'hesite pas d'utiliser leurs
> propres arguments pour pousser le projet, et minimise le cout financier. La
> mauvaise foi est dans ce cas essentielle.
> 2.1 Si le projet est accepte, cherche ailleurs, et vite :) 3. Le projet
> devra en toute logique etre refuse, n'hesite pas a repliquer de facon
> systematique avec le cout du projet si jamais on te ressort cette connerie.
>
> Certes les choses ne vont pas etre si simples, mais si jamais tu
> t'ennuies, ca vaut la peine d'essayer cet exercice. Peut-etre ca va finir
> avec une presentation (?? FrNOG ou similaire ??) sur l'interet de
> l'opensource en entreprise.
>
>
> ---
> 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] Mail (smtp/ pop / imap) laposte.net hs ?

[Louis Rouxel]

Hello à tous,


Visiblement, le problème se produit quand on omet "@laposte.net" dans le
login (pop, imap, smtp).
C'était toléré avant, mais plus maintenant.

La solution de contournement, en attendant résolution du problème, consiste
donc simplement à rajouter "@laposte.net" dans l'identifiant.


--
Louis Rouxel


On Thu, Jan 23, 2020 at 11:56 AM François Otho  wrote:

> - Mail original -
> > De: "Clément ANNEHEIM - CIRTEL" 
> > Envoyé: Jeudi 23 Janvier 2020 10:59:36
> > Objet: Re: [FRnOG] [MISC] Mail (smtp/ pop / imap) laposte.net hs ?
> >
> > Salut,
> >
> > J'ai aussi des problèmes similaires de login, chez Orange et chez
> > Laposte.
>
> Les PTT c'est fini depuis longtemps !
> Et les P d'encore plus longtemps ;-)
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [MISC] Mail (smtp/ pop / imap) laposte.net hs ?

[Louis Rouxel]

Hello,


Laposte.net a entamé hier une grosse migration de leurs plateformes.

Vu avec quelqu'un chez eux:


> *Oui, il se peut qu’il y ait des perturbations pop/imap/smtp. Cela va
> durer encore quelques jours.Si ça continue, il ne faut pas hésiter à
> contacter le service client : https://aide.laposte.net/indexForm.php
> <https://aide.laposte.net/indexForm.php>*


Bon courage!


--
Louis Rouxel


On Thu, Jan 23, 2020 at 9:57 AM Cécile MARTRON via frnog 
wrote:

> Bonjour,
>
> J'ai depuis hier des erreurs sur mes MUA concernant laposte.net
> POP3 / IMAP / SMTP, tous me retournent une erreur de login/mdp.
>
> Le webmail quant a lui l'air de bien se porter (login/mdp usuels)
> Suis-je la seule ?
>
> --
> Cécile MARTRON
> 06 85 44 33 38
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [JOBS] [JOBS] [BAYONNE][BIARRITZ] Administrateur / Administratrice Télécoms & Réseaux chez l'opérateur IZARLINK

[Jean-Louis Mélin]

Bonjour à tous

IzarLink est un jeune opérateur télécom alternatif en pleine croissance, membre 
de l'AOTA, qui construit actuellement son Data Center de proximité.

Dans le cadre de l'extension de notre réseau, nous recherchons un(e) 
collaborateur(trice) motivé(e) par le déploiement et la gestion d'un  réseau 
opérateur de dernière génération en Fibre Optique dédié aux entreprises (FTTO) 
du Pays Basque et des Pays de l'Adour.

Possédant une bonne maîtrise des technologies opérateurs (routage OSPF/BGP, 
infrastructures MPLS/VPLS, administration SNMP, sécurisation des réseaux, ToIP 
...) et des plateformes serveurs (Linux, VMWARE/HYPER V) vous participez 
activement à l'extension de notre réseau et au support technique de nos Clients 
entreprises.

Vous avez une formation Bac+2 minimum dans la spécialisation Réseaux et 
Télécom, une première expérience significative dans la gestion de réseaux 
complexes et vous êtes attachés aux valeurs d'un opérateur local, alors 
rejoignez-nous !

Type de contrat : CDI à pourvoir immédiatement.
Rémunération : en fonction de l'expérience
Avantages : Mutuelle 100%, chèques déjeuners, large autonomie.

Cordialement
Jean-Louis Mélin

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

RE: [FRnOG] [MISC] Digital signage... OpenSource ?

[BELLOTTO Louis]

Hello,

Nous utilisons INNES on-premises avec une quinzaine d'écran
A voir la : https://www.innes.pro/fr/plugncast/
Il y a aussi une version saas.

Bon, ok, ce n'est pas open-source...


-
Louis


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Vincent 
SERELLE
Envoyé : mardi 17 décembre 2019 23:34
À : Jérôme Quintard 
Cc : frnog-m...@frnog.org
Objet : Re: [FRnOG] [MISC] Digital signage... OpenSource ?

Hello Jérôme,

Un petit tour du côté de Xibo qui propose ce que tu cherche on-premise et en 
saas (au cas où), avec la compatibilité nécessaire.

https://xibo.org.uk/

Vincent.

Le mar. 17 déc. 2019 à 21:27, Jérôme Quintard  a écrit :

> Salut à tous,
>
> Au rayon misc de la liste, certains d'entre vous ont-ils trouver des 
> outils de digital signage, open source, simple d'utilisation et 
> multi-écrans... compatible android ou rasp.
>
> Je trouve des tonnes de services, plus ou moins bien fait, plus ou 
> moins bien traduits mais tous ont la fâcheuse tendance d'être en SAAS 
> à l'écran et par mois... je dois équiper une cinquantaine de TV ça 
> commence à chiffrer pour un truc qui est plutôt simple...
>
> Merci pour vos idées...
>
> Jérôme
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


--
Vincent SERELLE

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


-
Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce 
message non conforme à sa destination, toute diffusion, copie ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
préalable. Son contenu ne saurait constituer en aucun cas un engagement 
contractuel, une offre de souscrire à quelconque produit ou instrument 
financier ou une sollicitation à investir de la part du Groupe La Française et 
toutes opinions exprimées dans ce message ne sauraient nécessairement refléter 
celle du Groupe La Française. Le contenu de cet email peut contenir des virus 
informatiques qui pourraient endommager votre système informatique. Bien que 
Groupe La Française ait pris toutes les précautions raisonnables pour minimiser 
ce risque, nous déclinons toute responsabilité pour tout dommage que vous 
pourriez subir en raison de virus informatiques. Si vous recevez ce courriel 
par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. 
Nous vous invitons à prendre connaissance de notre politique de confidentialité 
et de cookies en cliquant ici 
https://www.la-francaise.com/fr/politique-de-confidentialite-et-de-cookies/
-
This message and any attachments are confidential and may be legally privileged 
or otherwise protected from disclosure. It is intended only for the stated 
addressee(s). Any use, dissemination, copy or disclosure of this message not in 
accordance with its purpose, either in whole or in part, is prohibited without 
our prior formal approval. Its contents, given solely for information, does not 
constitute a commitment or an offer to subscribe to any financial product by La 
Française Group. Any opinion expressed in this email may not necessarily 
reflect the opinion of La Française Group. The content of this email may 
contain computer viruses that could damage your computer system. Although La 
Française Group has taken all reasonable precautions to minimize this risk, we 
decline any liability for any damage you may suffer due to computer viruses. If 
you are neither the addressee nor an authorized recipient of this message, 
please notify the sender of receipt immediately and delete this message from 
your system. We invite you to read our privacy and cookies policy available on 
the Group’s website by clicking here 
https://www.la-francaise.com/en/privacy-and-cookies-policy/

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

Re: [FRnOG] [TECH] options LibreNMS

[Louis]

On avait des montées en CPU de la FPC > 80% sur les QFX-5100 / QFX-5110
lors des discovery - toutes les 6h - qui se faisaient en même temps que sur
les pollings.

On a aussi eu des problèmes de BFD mc-lag down sur les QFX10K lors des
pollings. On a jamais su si c'était dû à un traceoption activé en all sur
snmp. La recommandation de Juniper est d'augmenter le timer BFD lié à ICCP.

Sur les EX, j'ai pas observé de pb. Au temps pour moi.

Le lun. 28 oct. 2019 à 21:49, Michel Py 
a écrit :

> > Louis a écrit :
> > Ce post m'a bien aidé. Merci
> > J'ai mis le paramètre en global pour tous les JunOS. On avait des
> problèmes sur les EX et QFX.
> > $config[‘os’][‘junos’][‘snmp_max_oid’] = 1;
>
> Est-ce qu'on peut faire plus précis ? par modèle ?
> Je n'ai pas encore regardé dans les détails mais je lis avec attention.
>
> Michel.
>
>

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

Re: [FRnOG] [TECH] options LibreNMS

[Louis]

les paramètres par défaut de librenms pour max_oid.

Le lun. 28 oct. 2019 à 11:43, Alarig Le Lay  a écrit :

> On 28/10/2019 11:09, Louis wrote:
> > J'ai mis le paramètre en global pour tous les JunOS. On avait des
> problèmes
> > sur les EX et QFX.
>
> T’avais quoi comme problème ?
>
> --
> Alarig
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] options LibreNMS

[Louis]

Ce post m'a bien aidé. Merci

J'ai mis le paramètre en global pour tous les JunOS. On avait des problèmes
sur les EX et QFX.

$config[‘os’][‘junos’][‘snmp_max_oid’] = 1;

Le dim. 27 oct. 2019 à 14:29, Raphael Mazelier  a écrit :

> Devant la demande populaire je viens de retrouver ça. C'est très très
> quick and dirty (aka très moche).
>
> Cela se base sur une très vielle version d'observium, mais je viens de
> regarder le code de librenms cela n'a pas l'air bien différent.
>
> Donc pour les aventureux c'est ici :
>
>
> https://github.com/ut0mt8/observium/blob/master/includes/polling/ports-cached.inc.php
> (qui est une version modifiée de ports.inc.php)
>
> et
>
>
> https://github.com/ut0mt8/observium/blob/master/includes/polling/functions.inc.php
> (chercher BROKEN-SW-HW).
>
> Cela ne devrait pas être trop dur à adapter.
>
> Bon dimanche.
>
> --
>
> Raphael
>
>
>
> On 26/10/2019 19:40, Boris PASCAULT wrote:
> > Bonjoir,
> >
> > Effectivement, mais ça peut prendre du temps pour faire le ménage...
> >
> > Je suis aussi preneur des patchs, il y a surement moyen de le proposer
> sur
> > leur Git.
> >
> > Bonne soirée,
> >
> > Boris
> >
> > Le sam. 26 oct. 2019 à 14:59, Alarig Le Lay  a
> écrit :
> >
> >> On ven. 25 oct. 21:10:45 2019, Michel Py wrote:
> >>> Pour ceux qui ne se rendent pas compte à quel point LibreNMS c'est
> >>> brutal, sur un Catalyst c6509 il découvre et graphe pas moins de 143
> >>> sondes de température.
> >> Un bon 6500 est un 6500 éteint.
> >>
> >> --
> >> Alarig
> >>
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >>
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Raspberry Pi 4

[Louis]

Attention aux raspberry non officiels sur un réseau d'entreprise. Avec une
simple carte 4G en plus, quasi indétectable car le vol de données ne passe
pas par la sortie internet officielle.

https://www.01net.com/actualites/comment-un-simple-raspberry-pi-a-permis-le-piratage-de-la-nasa-1719376.html


Le mer. 26 juin 2019 à 10:40, David Ponzone  a
écrit :

> Toujours pas de POE-in natif ?
>
> > Le 26 juin 2019 à 01:23, Michel Py 
> a écrit :
> >
> > Wow, vous avez vu le nouveau Pi 4 ?
> > USB 3.0, jusqu'à 4GO de mémoire, vrai GigE, double monitor.
> >
> > https://www.raspberrypi.org/products/raspberry-pi-4-model-b/
> >
> > Michel.
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] PBR sur CheckPoint

[Louis]

La cli IP de checkpoint gaia est juste une interface d'iproute2 sous linux.
Vérifie ton PBR en mode expert via les commandes ip route et ip rule list -
https://blog.scottlowe.org/2013/05/29/a-quick-introduction-to-linux-policy-routing/.
Fais des tcpdump.

De mémoire, l'ordre de traitement du paquet :
1. nat de l'IP source
2. firewalling
3. routage par iproute2
4. nat de l'IP destination

donc iproute2 voit juste l'IP source nattée pas celle destination.

Le mer. 26 juin 2019 à 10:50, Louis  a écrit :

> Bonjour,
>
> sauf erreur, checkpoint se contre-fiche des adresses MAC. Ca a l'air d'une
> fausse piste.
>
>
> Le mar. 25 juin 2019 à 19:49, Michel KOENIG 
> a écrit :
>
>> Suite des recherches, je penses que c'est un problème d'adresses MAC
>>
>> Le flux sortant va vers la MAC du VRRP
>>
>> Le retour se présente avec la MAC du boitier qui est actif
>>
>> Donc, 2 possibilité pour corriger :
>>
>> 1/
>> Désactiver le check des tables d'adresses mac pour cette IP sur le
>> CheckPoint
>>
>> 2/
>> Obliger le PepLink a répondre avec sa MAC VRRP
>>
>> Quelqu'un a l'astuce pour un de ces point ?
>>
>> Merci
>>
>> Michel
>>
>> -Message d'origine-
>> De : David Ponzone 
>> Envoyé : mardi 25 juin 2019 17:08
>> À : Michel KOENIG 
>> Cc : frnog-t...@frnog.org
>> Objet : Re: [FRnOG] [TECH] PBR sur CheckPoint
>>
>>
>>
>> > Le 25 juin 2019 à 16:58, Michel KOENIG  a
>> écrit :
>> >
>> > Bonjour,
>> >
>> > Nous souhaitons faire une maquette avec PepLink derrière un CheckPoint
>> >
>> > Le problème semble se situer au niveau de la config de la PBR sur le
>> checkpoint
>> >
>> > Le routage s'effectue bien en sortie mais pas de paquet en retour
>>
>> Question con, mais ton PBR sur le Checkpoint respecte le NAT de
>> l’interface de sortie ?
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>

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

Re: [FRnOG] [TECH] PBR sur CheckPoint

[Louis]

Bonjour,

sauf erreur, checkpoint se contre-fiche des adresses MAC. Ca a l'air d'une
fausse piste.


Le mar. 25 juin 2019 à 19:49, Michel KOENIG  a
écrit :

> Suite des recherches, je penses que c'est un problème d'adresses MAC
>
> Le flux sortant va vers la MAC du VRRP
>
> Le retour se présente avec la MAC du boitier qui est actif
>
> Donc, 2 possibilité pour corriger :
>
> 1/
> Désactiver le check des tables d'adresses mac pour cette IP sur le
> CheckPoint
>
> 2/
> Obliger le PepLink a répondre avec sa MAC VRRP
>
> Quelqu'un a l'astuce pour un de ces point ?
>
> Merci
>
> Michel
>
> -Message d'origine-
> De : David Ponzone 
> Envoyé : mardi 25 juin 2019 17:08
> À : Michel KOENIG 
> Cc : frnog-t...@frnog.org
> Objet : Re: [FRnOG] [TECH] PBR sur CheckPoint
>
>
>
> > Le 25 juin 2019 à 16:58, Michel KOENIG  a
> écrit :
> >
> > Bonjour,
> >
> > Nous souhaitons faire une maquette avec PepLink derrière un CheckPoint
> >
> > Le problème semble se situer au niveau de la config de la PBR sur le
> checkpoint
> >
> > Le routage s'effectue bien en sortie mais pas de paquet en retour
>
> Question con, mais ton PBR sur le Checkpoint respecte le NAT de
> l’interface de sortie ?
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] RFC 8404: Effects of Pervasive Encryption on Operators

[Louis]

Le problème des solutions à base de squidguard, c'est qu'elles utilisent
des blacklists gérées par des humains.

Les DNS menteurs de contrôle parental dispo sur internet utilisent des
algorithmes pour catégoriser les sites. C'est beaucoup plus fiable. Ex :
https://dns.yandex.com/
https://www.opendns.com/setupguide/#familyshield

Après, les DNS menteurs sont facilement contournables (DNS over https,
/etc/hosts...) sauf si on vérifie que l'IP destination est bien celle
donnée par le DNS menteur. C'est l'objet de ce projet :
https://github.com/luigi1809/webfilter-ng (option DNS filtering).
Fonctionne sur debian 9 , ubuntu >= 16.04, rapsbian pour Raspberry.

Et puis avec Squid, SquidGuard, vous serez obligé de renseigner un proxy
sur les postes. webfilter-ng filtre en mode transparent sur le routeur sans
proxying.

Le jeu. 29 nov. 2018 à 19:26,  a écrit :

> On mardi 27 novembre 2018 11:35:49 CET Thierry Chich - thierry.chich@ac-
> clermont.fr wrote:
> > Le 26/11/2018 à 15:53, Bruno Pagani a écrit :
> > > Et c’est tant mieux, car c’est effectivement un gros manque pour la
> > > protection de la vie privée.
> > >
> > > La réponse pour la protection des enfants, c’est que ça se passe sur le
> > > terminal de l’utilisateur, pas ailleurs sur le chemin. Si on n’est pas
> > > capable de contrôler le terminal des enfants et l’usage qu’ils en font,
> > > le problème ne se situe pas au niveau des protocoles utilisés sur
> > > Internet.
> >
> > Ca, c'est la théorie. La pratique, c'est qu'il n'y a rien. On a family
> > link sur android, un truc chez apple, un peu du n'importe quoi sur les
> > PC, mais rien qui soit simple, centralisable, gérable depuis une école
> > ou un collège.
> >
> > Thierry
>
> Ça s'appelle un proxy.
>
> privoxy + dansguardian qui fait une analyse heuristique des pages web,
> squid +
> squidguard qui utilise une liste de sites à filtrer[0] ou un blocage par
> défaut et une liste blanche de sites autorisés.
>
> Apparemment ça s'appelle maintenant smoothwall[1] qui est derrière
> dansguardian, squidguard et urlblacklist.com: et ils ont une offre dédiée
> au
> monde de l'éducation.
>
> Il y a aussi des tutos en français[2] et ça peut même tourner à la maison
> sur
> une Raspberry Pi[3].
>
> [0]: http://dsi.ut-capitole.fr/blacklists/
> [1]: https://www.smoothwall.com/
> [2]: http://lesaventuresdeyannigdanslemondeit.blogspot.com/2013/03/
> configuration-de-squidguard-comme.html
> 
> [3]:
> https://www.pihomeserver.fr/2015/09/01/un-controle-parental-grace-au-raspberry-pi-squid-et-squidguard/
>
>
>
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] Re: [MISC] Smartphone et enfants

[Louis]

> La mauvaise nouvelle c'est qu'il n'y a pas d'application pour recenser
> les SDF pour les prendre en charge afin de leur redonner leur humanité.

si https://www.entourage.social/

Le jeu. 29 nov. 2018 à 12:02, Stéphane Rivière  a écrit :

> Le 29/11/2018 à 11:56, Arnaud BRAND a écrit :
> > On parle plus aux gens. On préfère règler des problèmes humains avec des
> > solutions techniques. C'est moins salissant.
>
> Ca me fait penser à une application pour recenser les déchets sur les
> trottoirs. Plein de cases sont prévues pour préciser le type de déchet.
> Il n'y a pas de cases SDF. C'est une bonne nouvelle, les SDF ne sont pas
> (encore) des déchets.
>
> La mauvaise nouvelle c'est qu'il n'y a pas d'application pour recenser
> les SDF pour les prendre en charge afin de leur redonner leur humanité.
>
> --
> Stéphane Rivière
> Ile d'Oléron - France
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] Re: [TECH] RFC 8404: Effects of Pervasive Encryption on Operators

[Louis]

Pour ne pas filer du fric à symantec, Palo Alto etc, il faudrait de
vrais initiatives open-source fiables et simples à utiliser par Mme
Michu.

L'éducation, OK mais ce n'est pas suffisant. Les parents sont dépassés
par les usages d'Internet. Les gamins se retrouvent parfois face à des
contenus qu'ils ne voulaient pas voir - par exemple par le biais de
sites de streaming sur lesquels ils regardaient leurs dessins animés.

Le 28/11/2018, Stephane Bortzmeyer a écrit :
> On Tue, Nov 27, 2018 at 11:48:27AM +0100,
>  Refuznik  wrote
>  a message of 48 lines which said:
>
>> Pour un collège comme pour une entreprise on embauche un adminsys
>> qui mettra en place une solution adaptée.
>
> En tant qu'ex parent d'élève, je préférerais qu'on embauche des profs,
> des bibliothécaires pour le CDI et autres employés au contact avec les
> enfants. (Plutôt que de filer du fric à Symantec ou Palo Alto pour
> faire un filtrage automatique selon les critères des puritains
> états-uniens.)
>
> L'éducation, ce ne sont pas des protections techniques, ce sont des
> adultes disponibles. (Ma politique à la maison était de ne jamais dire
> « il faut pas déranger Papa, il travaille »)
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


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

Re: [FRnOG] [TECH] Filtrage http / https transparent (was: Filtrage https par Certificate Name CN)

[Louis]

Esni, c'est de la pervasive encryption :p

De toute façon, il y aura toujours des solutions pour faire du filtrage

Le 27/11/2018, Raphael Jacquot a écrit :
>
>
> On 11/27/18 4:50 PM, Louis wrote:
>
>> Les flux ne sont pas déchiffrés - pas besoin donc d'installer de
>> certificats racines sur la machine. Le filtrage https est basé sur le tag
>> SNI de TLS et non sur les certificates name CN.
>>
>> Louis
>
> jusqu'a ce que la mise en place de esni soit suffisamment complete...
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


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

Re: [FRnOG] [TECH] Filtrage http / https transparent (was: Filtrage https par Certificate Name CN)

[Louis]

Esni, c'est de la pervasive encryption :p

De toute façon, il y aura toujours des solutions pour faire du filtrage

Le 27/11/2018, Raphael Jacquot a écrit :
>
>
> On 11/27/18 4:50 PM, Louis wrote:
>
>> Les flux ne sont pas déchiffrés - pas besoin donc d'installer de
>> certificats racines sur la machine. Le filtrage https est basé sur le tag
>> SNI de TLS et non sur les certificates name CN.
>>
>> Louis
>
> jusqu'a ce que la mise en place de esni soit suffisamment complete...
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


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

Re: [FRnOG] [TECH] Filtrage http / https transparent (was: Filtrage https par Certificate Name CN)

[Louis]

Bonjour,

pour info, je n'ai pas utilisé squid + squidguard qui ne me permettait pas
de faire du filtrage en mode transparent.

Comme je n'ai rien trouvé d'existant en open-source pour faire du filtrage
en mode transparent, j'ai développé un outil open-source pour se faire :

https://github.com/luigi1809/webfilter-ng

Les flux ne sont pas déchiffrés - pas besoin donc d'installer de
certificats racines sur la machine. Le filtrage https est basé sur le tag
SNI de TLS et non sur les certificates name CN.

Louis

Le ven. 25 mai 2018 à 17:06, Félix Bouynot  a
écrit :

> Bonjour,
>
> Avec Squid c'est 3 lignes :
>
> acl DiscoverSNIHost at_step SslBump1
> ssl_bump peek DiscoverSNIHost
> ssl_bump splice all
>
> Tu lis le nom de domaine puis tu tunnelles. (le strict minimum donc, tu
> casses rien même en cas de HSTS+HPKP, tu espionnes rien d'autre que le
> nom de domaine)
> Pour le filtrage t'as plus qu'à suivre un tutoriel squidguard.
>
> Félix
>
> Le vendredi 25 mai 2018 à 15:58 +0200, Louis a écrit :
> > Bonjour,
> >
> > je cherche une solution open-source pour faire du filtrage https par
> > Certificate Name (transmis en clair par le serveur à l'établissement de
> la
> > session) à base de blacklist.
> >
> > Je vois que fortigate propose quelque chose du genre (sans gestion de
> > blacklist à première vue):
> >
> > http://kb.fortinet.com/kb/viewContent.do?externalId=FD31710 (solution
> 1).
> >
> > Je cherche idéalement à faire ça avec squid et squidguard.
> >
> > merci de votre aide!
> >
> > Louis
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>

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

Re: [FRnOG] [MISC] FRnOG 31.0 - RELEASE

[Louis]

Bonjour,

est-ce que quelqu'un libérerait sa place demain après-midi ? Je suis
preneur.

Louis

Le mar. 2 oct. 2018 à 13:11, Philippe Bourcier  a
écrit :

>
> Bonjour,
>
> La réunion FRnOG est ce vendredi.
>
> Le programme final est en ligne :
> http://www.frnog.org/?page=frnog31
>
> Merci à nos sponsors.
>
>
> Cordialement,
> --
> Philippe Bourcier
> web : http://sysctl.org/
> blog : https://www.linkedin.com/today/author/philippebourcier
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [TECH] Documentation API fortigate

[Louis]

Bonjour,

je cherche une doc qui décrive l'usage des API sur fortigate.

Je vois qu'il y a une API dispo mais elle n'a pas l'air documentée. Je me
trompe ?

https://github.com/openstack/networking-fortinet/blob/5ca7b1b4c17240c8eb1b60f7cfa9a46b5b943718/networking_fortinet/api_client/templates.py

Par exemple :

https://fortigate/api/v2/cmdb/router/static/

cordialement,

Louis

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

Re: [FRnOG] [TECH] FAI et routeurs OneAccess

[Louis]

bien vu pour pcengines

Openwrt, pas fan.

Le 5 septembre 2018 à 11:37, Kevin CHAILLY | Service Technique <
kchai...@adeo-informatique.com> a écrit :

> Pour le coté soft OK,
>
> mais sur un nombre conséquent de matériels, tu vas pouvoir coller du
> OpenWRT,
>
> ou si tu prends du pcengines, vu la puissance de la carte et son archi
> intel 64b tu peux y coller ce que tu veux.
>
>
> Cordialement,
>
> [image: logo] <http://www.adeo-informatique.com>  Kevin CHAILLY | Service
> Technique
>  Tel : 04 688 24 688  | Fax : 04 69 96 17 75
> GROUPE
> GLOBAL DYNAMICS  > MAS GUERIDO - 10 RUE A. EINSTEIN 66330 CABESTANY
> <https://www.google.com/maps/place/10+Rue+Albert+Einstein/@42.6892553,2.9254476,1673m/data=%213m1%211e3%214m2%213m1%211s0x12b06f9325319cbf:0x8a2a5130fd72fda?hl=fr>
> <https://www.google.com/maps/place/10+Rue+Albert+Einstein/@42.6892553,2.9254476,1673m/data=%213m1%211e3%214m2%213m1%211s0x12b06f9325319cbf:0x8a2a5130fd72fda?hl=fr>
>  > WWW.ADEO-INFORMATIQUE.FR
>
> --
> *De :* Louis 
> *Envoyé :* mercredi 5 septembre 2018 11:19:55
> *À :* Kevin CHAILLY | Service Technique
> *Cc :* Olivier MORFIN; frnog-tech
>
> *Objet :* Re: [FRnOG] [TECH] FAI et routeurs OneAccess
>
> Je voulais dire pas dépendant d'un fournisseur pour le soft. Plus de
> réponse du genre : it's not a bug, it's a feature.
>
> Mais c'est sûr ça demande de s'investir dans l'open-source mais c'est
> rentable à la longue.
>
> Le 5 septembre 2018 à 11:01, Kevin CHAILLY | Service Technique <
> kchai...@adeo-informatique.com> a écrit :
>
>> Le problème avec cette solution,
>>
>>
>> C'est que du coup tu es dépendant de 3 fournisseurs :(
>>
>>
>> - Raspi foundation pour ton SBC
>>
>> - Le fournisseur du Shield 4G
>>
>> - Le fournisseur du Modem 4G
>>
>>
>> Les antennes sont plutôt faiblounes et ce produit demande beaucoup de
>> fabrication !
>>
>>
>> Je n'arrive pas a voir un intérêt pour cette solution, sauf a faire
>> piloter du GPIO a la Raspi,
>>
>>
>> En modem 4G le choix est pléthorique, tu as du très bon matos chez
>> MikroTik, Teltonika,
>>
>>
>> Chez nous on a même fait des tests avec du TP-Link TL-MR6400 avec un
>> certain succès.
>>
>>
>> Cordialement,
>>
>> [image: logo] <http://www.adeo-informatique.com>  Kevin CHAILLY |
>> Service Technique
>>  Tel : 04 688 24 688  | Fax : 04 69 96 17 75
>> GROUPE
>> GLOBAL DYNAMICS  > MAS GUERIDO - 10 RUE A. EINSTEIN 66330 CABESTANY
>> <https://www.google.com/maps/place/10+Rue+Albert+Einstein/@42.6892553,2.9254476,1673m/data=%213m1%211e3%214m2%213m1%211s0x12b06f9325319cbf:0x8a2a5130fd72fda?hl=fr>
>> <https://www.google.com/maps/place/10+Rue+Albert+Einstein/@42.6892553,2.9254476,1673m/data=%213m1%211e3%214m2%213m1%211s0x12b06f9325319cbf:0x8a2a5130fd72fda?hl=fr>
>>  > WWW.ADEO-INFORMATIQUE.FR
>>
>>
>>
>> --
>> *De :* frnog-requ...@frnog.org  de la part de
>> Louis 
>> *Envoyé :* mercredi 5 septembre 2018 10:37
>> *À :* Olivier MORFIN
>> *Cc :* frnog-tech
>> *Objet :* Re: [FRnOG] [TECH] FAI et routeurs OneAccess
>>
>> Tu peux te faire ton propre routeur 4G sur raspberry. Dans la liste de
>> course :
>>
>>- Sixfab Pi 3G-4G/LTE Base Shield V2
>>- Modem Quectel EC25
>>- 2 Antennes IPEX
>>
>>
>> Tu ne seras pas dépendant d'un fournisseur
>>
>> Le 5 septembre 2018 à 10:16, Olivier MORFIN  a
>> écrit :
>>
>> > Bonjour,
>> > je découvre la liste FRNOG et je ne suis pas déçu ! Ça répond :) Merci
>> les
>> > gars.
>> >
>> > Dans l'idéal, j'aimerai trouver des CPE capables de router 100M, et qui
>> > intègrent un modem 4G. Pour les SDSL et FO, je préfère conserver
>> > l'équipement de terminaison Opérateur (OneAccess, RAD, et consort), et
>> donc
>> > j'ai juste besoin d'un port ether cuivre.
>> > Et pour l'ADSL, pas besoin.
>> >
>> > Du coup :
>> > ONEACCESS : ce que j'en conclus c'est que pour que ce soit intéressant
>> > niveau prix, nous sommes trop petit. Si je me trompe, je veux bien un
>> ordre
>> > d'idée de prix pour un produit respectant les précos ci-dessus si
>> quelqu'un
>> > sais :)
>> > MIKROTIK : j'avoue que je me penche sur le sujet... mais pour avoir de
>> la
>> > 4G, il faut forcement partir sur les RouterBoards! J'aimerai trouver un
>> > produit fini.
>> > UBIQUITI : Je kiff leur Cli

Re: [FRnOG] [TECH] FAI et routeurs OneAccess

[Louis]

Je voulais dire pas dépendant d'un fournisseur pour le soft. Plus de
réponse du genre : it's not a bug, it's a feature.

Mais c'est sûr ça demande de s'investir dans l'open-source mais c'est
rentable à la longue.

Le 5 septembre 2018 à 11:01, Kevin CHAILLY | Service Technique <
kchai...@adeo-informatique.com> a écrit :

> Le problème avec cette solution,
>
>
> C'est que du coup tu es dépendant de 3 fournisseurs :(
>
>
> - Raspi foundation pour ton SBC
>
> - Le fournisseur du Shield 4G
>
> - Le fournisseur du Modem 4G
>
>
> Les antennes sont plutôt faiblounes et ce produit demande beaucoup de
> fabrication !
>
>
> Je n'arrive pas a voir un intérêt pour cette solution, sauf a faire
> piloter du GPIO a la Raspi,
>
>
> En modem 4G le choix est pléthorique, tu as du très bon matos chez
> MikroTik, Teltonika,
>
>
> Chez nous on a même fait des tests avec du TP-Link TL-MR6400 avec un
> certain succès.
>
>
> Cordialement,
>
> [image: logo] <http://www.adeo-informatique.com>  Kevin CHAILLY | Service
> Technique
>  Tel : 04 688 24 688  | Fax : 04 69 96 17 75
> GROUPE
> GLOBAL DYNAMICS  > MAS GUERIDO - 10 RUE A. EINSTEIN 66330 CABESTANY
> <https://www.google.com/maps/place/10+Rue+Albert+Einstein/@42.6892553,2.9254476,1673m/data=%213m1%211e3%214m2%213m1%211s0x12b06f9325319cbf:0x8a2a5130fd72fda?hl=fr>
> <https://www.google.com/maps/place/10+Rue+Albert+Einstein/@42.6892553,2.9254476,1673m/data=%213m1%211e3%214m2%213m1%211s0x12b06f9325319cbf:0x8a2a5130fd72fda?hl=fr>
>  > WWW.ADEO-INFORMATIQUE.FR
>
>
>
> --
> *De :* frnog-requ...@frnog.org  de la part de
> Louis 
> *Envoyé :* mercredi 5 septembre 2018 10:37
> *À :* Olivier MORFIN
> *Cc :* frnog-tech
> *Objet :* Re: [FRnOG] [TECH] FAI et routeurs OneAccess
>
> Tu peux te faire ton propre routeur 4G sur raspberry. Dans la liste de
> course :
>
>- Sixfab Pi 3G-4G/LTE Base Shield V2
>- Modem Quectel EC25
>- 2 Antennes IPEX
>
>
> Tu ne seras pas dépendant d'un fournisseur
>
> Le 5 septembre 2018 à 10:16, Olivier MORFIN  a
> écrit :
>
> > Bonjour,
> > je découvre la liste FRNOG et je ne suis pas déçu ! Ça répond :) Merci
> les
> > gars.
> >
> > Dans l'idéal, j'aimerai trouver des CPE capables de router 100M, et qui
> > intègrent un modem 4G. Pour les SDSL et FO, je préfère conserver
> > l'équipement de terminaison Opérateur (OneAccess, RAD, et consort), et
> donc
> > j'ai juste besoin d'un port ether cuivre.
> > Et pour l'ADSL, pas besoin.
> >
> > Du coup :
> > ONEACCESS : ce que j'en conclus c'est que pour que ce soit intéressant
> > niveau prix, nous sommes trop petit. Si je me trompe, je veux bien un
> ordre
> > d'idée de prix pour un produit respectant les précos ci-dessus si
> quelqu'un
> > sais :)
> > MIKROTIK : j'avoue que je me penche sur le sujet... mais pour avoir de la
> > 4G, il faut forcement partir sur les RouterBoards! J'aimerai trouver un
> > produit fini.
> > UBIQUITI : Je kiff leur Cli !! Les produits sont pas mal du tout, mais
> pas
> > de 4G :(  (du moins intégré)
> > TECHNICOLOR : Si je me trompe pas, c'est uniquement ADSL/VDSL ? Donc pas
> > intéressant pour nous.
> > AETHRA : Ca m'a l'air pas mal, je ne connais pas. Je vois des modèles
> > comme le AS6060LW qui pourrait convenir. Quelqu'un à une idée de prix à
> la
> > louche ? Une une autre ref qui pourrait convenir ?
> >
> > A plus tard.
> >
> >
> >
> > Le mer. 5 sept. 2018 à 09:52, David Touitou  a
> > écrit :
> >
> >> Bonjour,
> >>
> >> ça causait module VDSL en SFP.
> >>
> >> > Effectivement on utilise ce module SFP qu'on a validé
> >> > Ca marche très bien
> >>
> >> Avec quelle plateforme ?
> >>
> >> J'ai trouvé des Ubiquiti ou des Mikrotik (et RouterBoards).
> >> Mais des SBC sur lesquels faire tourner pfSense/opnSense, c'est plus
> >> compliqué...
> >>
> >> David
> >>
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] FAI et routeurs OneAccess

[Louis]

Mon système est en read-only.

J'ai suivi le tutoriel : https://hallard.me/raspberry-pi-read-only/

Le 5 septembre 2018 à 10:41, Richard Klein  a écrit :

> Bonjour ,
>
> Le problème du raspberry c'est l’usure de la SD avec les cycles d’écriture.
> Donc il faudra limiter les logs ou creer un RAMDisk pour limiter les
> cycles d'ecritures.
>
> Richard
>
> My two Framboises
>
> Le mer. 5 sept. 2018 à 10:38, Louis  a écrit :
>
>> Tu peux te faire ton propre routeur 4G sur raspberry. Dans la liste de
>> course :
>>
>>- Sixfab Pi 3G-4G/LTE Base Shield V2
>>- Modem Quectel EC25
>>- 2 Antennes IPEX
>>
>>
>> Tu ne seras pas dépendant d'un fournisseur
>>
>> Le 5 septembre 2018 à 10:16, Olivier MORFIN  a
>> écrit :
>>
>> > Bonjour,
>> > je découvre la liste FRNOG et je ne suis pas déçu ! Ça répond :) Merci
>> les
>> > gars.
>> >
>> > Dans l'idéal, j'aimerai trouver des CPE capables de router 100M, et qui
>> > intègrent un modem 4G. Pour les SDSL et FO, je préfère conserver
>> > l'équipement de terminaison Opérateur (OneAccess, RAD, et consort), et
>> donc
>> > j'ai juste besoin d'un port ether cuivre.
>> > Et pour l'ADSL, pas besoin.
>> >
>> > Du coup :
>> > ONEACCESS : ce que j'en conclus c'est que pour que ce soit intéressant
>> > niveau prix, nous sommes trop petit. Si je me trompe, je veux bien un
>> ordre
>> > d'idée de prix pour un produit respectant les précos ci-dessus si
>> quelqu'un
>> > sais :)
>> > MIKROTIK : j'avoue que je me penche sur le sujet... mais pour avoir de
>> la
>> > 4G, il faut forcement partir sur les RouterBoards! J'aimerai trouver un
>> > produit fini.
>> > UBIQUITI : Je kiff leur Cli !! Les produits sont pas mal du tout, mais
>> pas
>> > de 4G :(  (du moins intégré)
>> > TECHNICOLOR : Si je me trompe pas, c'est uniquement ADSL/VDSL ? Donc pas
>> > intéressant pour nous.
>> > AETHRA : Ca m'a l'air pas mal, je ne connais pas. Je vois des modèles
>> > comme le AS6060LW qui pourrait convenir. Quelqu'un à une idée de prix à
>> la
>> > louche ? Une une autre ref qui pourrait convenir ?
>> >
>> > A plus tard.
>> >
>> >
>> >
>> > Le mer. 5 sept. 2018 à 09:52, David Touitou 
>> a
>> > écrit :
>> >
>> >> Bonjour,
>> >>
>> >> ça causait module VDSL en SFP.
>> >>
>> >> > Effectivement on utilise ce module SFP qu'on a validé
>> >> > Ca marche très bien
>> >>
>> >> Avec quelle plateforme ?
>> >>
>> >> J'ai trouvé des Ubiquiti ou des Mikrotik (et RouterBoards).
>> >> Mais des SBC sur lesquels faire tourner pfSense/opnSense, c'est plus
>> >> compliqué...
>> >>
>> >> David
>> >>
>> >
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>

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

Re: [FRnOG] [TECH] FAI et routeurs OneAccess

[Louis]

Tu peux te faire ton propre routeur 4G sur raspberry. Dans la liste de
course :

   - Sixfab Pi 3G-4G/LTE Base Shield V2
   - Modem Quectel EC25
   - 2 Antennes IPEX

Tu ne seras pas dépendant d'un fournisseur

Le 5 septembre 2018 à 10:16, Olivier MORFIN  a
écrit :

> Bonjour,
> je découvre la liste FRNOG et je ne suis pas déçu ! Ça répond :) Merci les
> gars.
>
> Dans l'idéal, j'aimerai trouver des CPE capables de router 100M, et qui
> intègrent un modem 4G. Pour les SDSL et FO, je préfère conserver
> l'équipement de terminaison Opérateur (OneAccess, RAD, et consort), et donc
> j'ai juste besoin d'un port ether cuivre.
> Et pour l'ADSL, pas besoin.
>
> Du coup :
> ONEACCESS : ce que j'en conclus c'est que pour que ce soit intéressant
> niveau prix, nous sommes trop petit. Si je me trompe, je veux bien un ordre
> d'idée de prix pour un produit respectant les précos ci-dessus si quelqu'un
> sais :)
> MIKROTIK : j'avoue que je me penche sur le sujet... mais pour avoir de la
> 4G, il faut forcement partir sur les RouterBoards! J'aimerai trouver un
> produit fini.
> UBIQUITI : Je kiff leur Cli !! Les produits sont pas mal du tout, mais pas
> de 4G :(  (du moins intégré)
> TECHNICOLOR : Si je me trompe pas, c'est uniquement ADSL/VDSL ? Donc pas
> intéressant pour nous.
> AETHRA : Ca m'a l'air pas mal, je ne connais pas. Je vois des modèles
> comme le AS6060LW qui pourrait convenir. Quelqu'un à une idée de prix à la
> louche ? Une une autre ref qui pourrait convenir ?
>
> A plus tard.
>
>
>
> Le mer. 5 sept. 2018 à 09:52, David Touitou  a
> écrit :
>
>> Bonjour,
>>
>> ça causait module VDSL en SFP.
>>
>> > Effectivement on utilise ce module SFP qu'on a validé
>> > Ca marche très bien
>>
>> Avec quelle plateforme ?
>>
>> J'ai trouvé des Ubiquiti ou des Mikrotik (et RouterBoards).
>> Mais des SBC sur lesquels faire tourner pfSense/opnSense, c'est plus
>> compliqué...
>>
>> David
>>
>

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

Re: [FRnOG] [TECH] 4G : agrégation de bandes

[Louis]

Merci de vos conseils. Je me suis fait avoir comme un débutant!!

J'ai acheté la mauvaise carte. Dommage.

Le 5 juillet 2018 à 14:31, Paul Rolland (ポール・ロラン)  a
écrit :

> Bonjour,
>
> On Thu, 5 Jul 2018 10:08:44 +0200
> Nicolas CORBEL  wrote:
>
> > Ton modem est - si j'en crois leur site - compatible LTE CAT4 donc pas de
> > CA. C'est donc normal de ne te connecter qu'à une bande.
>
> C'est ca. Pour faire du CA, il faut prendre les modeles plus recents que
> le EC25, comme par exemple le EP06.
>
>
> Paul
>
>

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

[FRnOG] [TECH] 4G : agrégation de bandes

[Louis]

Bonjour,

j'ai un modem quectel EC25 sous raspberry. Je peux m'y connecter à Internet
en 4G avec Bouygues.

Mais j'ai l'impression que l'agrégation de bandes LTE - Mimo - ne
fonctionne pas. D'après la datasheet, le modem est compatible mimo.

En débuggant avec des commandes AT, j'ai l'impression que je suis connecté
qu'à une seule bande B7.

+QENG: "servingcell","NOCONN","LTE","FDD",208,20,7A5C703,231,3175,*7*
,4,4,7533,-90,-6,-63,16,-

Cf doc
ftp://77.47.193.10/pub/pavlov/Distrib/UnitedHelp/Datasheet/Quectel%20EC25%20-%20Confidential/Software/

Notemment
ftp://77.47.193.10/pub/pavlov/Distrib/UnitedHelp/Datasheet/Quectel%20EC25%20-%20Confidential/Software/Quectel_EC25_QuecCell_AT_Commands_Manual_V1.1.pdf


J'ai des cellules voisines.

+QENG: "neighbourcell intra","LTE",3175,231,-6,-91,-63,0,-,-,-,-,-
+QENG: "neighbourcell intra","LTE",3175,232,-17,-103,-75,0,-,-,-,-,-
+QENG: "neighbourcell intra","LTE",3175,268,-18,-111,-86,0,-,-,-,-,-
+QENG: "neighbourcell intra","LTE",3175,269,-20,-114,-86,0,-,-,-,-,-

Comment faire fonctionner l'agrégation de bande ?

cordialement,

Louis

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

[FRnOG] [TECH] Filtrage https par Certificate Name CN

[Louis]

Bonjour,

je cherche une solution open-source pour faire du filtrage https par
Certificate Name (transmis en clair par le serveur à l'établissement de la
session) à base de blacklist.

Je vois que fortigate propose quelque chose du genre (sans gestion de
blacklist à première vue):

http://kb.fortinet.com/kb/viewContent.do?externalId=FD31710 (solution 1).

Je cherche idéalement à faire ça avec squid et squidguard.

merci de votre aide!

Louis

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

[FRnOG] [TECH] Logiciel schéma réseau

[Louis]

Bonjour,

quel logiciel utilisez-vous pour faire vos schémas réseaux ? Je me rends
compte que Visio me fait perdre à chaque fois énormément de temps pour un
résultat approximatif - mauvais alignement...

Je me dis qu'il doit y avoir mieux. Quand j'utilise GNS3, la vue graphique
réalise des schémas très facilement. Ce n'est pas adapté pour faire des
schémas complexes, certe, mais cela montre que Visio complique la tâche.

Jusqu'ici, j'ai testé des logiciels de schémas qui avaient l'air plus
simples mais le format de fichier est incompatible avec Visio (c'est quand
même le logiciel qui utilisé par tout le monde). Connaissez-vous plus
simple et compatible visio ?

Côté automatisation, le langage xml Visio est bien trop complexe pour
envisager la construction de schéma par script. Utilisez-vous des solutions
automatiques du commerce ? En êtes-vous satisfaits ?

Louis

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

[FRnOG] [JOBS] Offre d'emploi IZARLINK - Administrateur Réseaux & Systèmes (ToIP) - Bidart (64)

[Jean-Louis Mélin]

Bonjour à tous

Dans le cadre de l'évolution de notre activité d'opérateur, nous sommes en 
recherche d'un administrateur réseaux & systèmes (ToIP).
Le poste est basé à Bidart (64).
L'offre est consultable  sur https://www.izarlink.com/?p=841
N'hésitez pas à me contacter par mail pour plus d'informations.

Cordialement

[Logo_web_small]
Jean-Louis MÉLIN
Technopole IZARBEL
Terrasses Shannon
64 210 BIDART
www.izarlink.com<http://www.izarlink.com>
Mobile : +33(0)6 80 87 37 28
Mail: jlme...@izarlink.com<mailto:jlme...@izarlink.com>

  Izarlink est membre de l'AOTA
[aota_logotext]


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

RE: [FRnOG] [TECH] Uplink collecte FTTH

[Jean-Louis Mélin]

Ok pour la mutualisation sur l'arbre GPON mais à supposer 1G de boucle locale 
partagé avec 32 "fous furieux" (sur les 64 abonnés) cela fait quand même plus 
de 30 Mbits or j'arrive péniblement à 20 Mbits ! Je suppose que la limite ne 
provient pas de la boucle locale mais en amont. 
C'est pourquoi j'aimerais bien connaître les principes de contention appliqués 
pour le raccordement de toute une plaque FTTH sur le backbone.

Jean-Louis Mélin   


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

[FRnOG] [TECH] Uplink collecte FTTH

[Jean-Louis Mélin]

Hello,

Je me pose la question de savoir comment la collecte FTTH Orange est connectée 
sur le backbone ?
J'imagine que l'Uplink est partagé avec la collecte ADSL avec un débit plus 
important mais y a-t-il des règles d'ingénierie précises ?
Autre question corolaire, savez-vous si Orange a fait évoluer son backbone et 
ses liens longues distances pour supporter les collectes FTTH ?
En effet, sur l'agglomération de Bayonne, le débit FTTH est mauvais vers 19h et 
cela correspond à peu près à l'expérience vécue auparavant en ADSL.

Merci pour vos réponses.

Jean-Louis Mélin

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

Re: [FRnOG] [MISC] Compte cisco.pearsoncred.com

[Louis]

merci le site de Thomas a fonctionné. Pearson ne m'avait pas aidé.

Le 30 novembre 2017 à 15:07, Franck LABBE <fra...@e-labbe.eu> a écrit :

> J'ai eu le mémé cas que toi l'année dernière.
> Je m'en été sorti en envoyant un mail à pearson (je ne retrouve pas
> l'adresse)
> Mais de mémoire, ça avait pris un peu de temps...
> Bon courage
>
>
> Franck Labbé
>
> Le 30 novembre 2017 à 13:17, Louis <luigi.1...@gmail.com> a écrit :
>
>> Bonjour,
>>
>> j'ai un compte Cisco Certification Tracking System cisco.pearsoncred.com
>> associé à l'email de mon ancienne société. Je n'arrive pas à me connecté
>> et
>> l'email de reset du mot de passe ne peut pas m'être envoyé. Il n'a pas
>> encore été fusionné avec mon compte CSCO de cisco.com.
>>
>> Est-ce que quelqu'un saurait comment me débloquer? Aucun numéro de
>> téléphone sur le site. Peut-être quelqu'un de chez cisco?
>>
>> merci!
>>
>> Louis
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>

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

[FRnOG] [MISC] Compte cisco.pearsoncred.com

[Louis]

Bonjour,

j'ai un compte Cisco Certification Tracking System cisco.pearsoncred.com
associé à l'email de mon ancienne société. Je n'arrive pas à me connecté et
l'email de reset du mot de passe ne peut pas m'être envoyé. Il n'a pas
encore été fusionné avec mon compte CSCO de cisco.com.

Est-ce que quelqu'un saurait comment me débloquer? Aucun numéro de
téléphone sur le site. Peut-être quelqu'un de chez cisco?

merci!

Louis

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

Re: Fwd: [FRnOG] [TECH] Faille WPA2

[Louis]

non. Il y a 10 failles dont 9 côté client et une côté AP.

Il faut patcher les clients et les AP (ou désactiver 802.11r sur l'AP).

Savez-vous si il y aurait des moyens de détecter un client qui utilise un
algorithme WPA/WPA2 non patché et donc de lui interdire l'accès à l'AP ?

Louis

Le 19 octobre 2017 à 16:12, Pierre Colombier <pcdw...@pcdwarf.net> a écrit :

> Si j'ai bien compris le papier, la faille est dans le client, pas dans
> l'AP ?
>
>
>
>
> On 18/10/2017 14:39, randria.nicolas wrote:
>
>> Pour info, le papier original est ici:
>> https://papers.mathyvanhoef.com/ccs2017.pdf
>>
>> Les maintainers de wpa_supplicant on corrigé la faille dans la derniere
>> MAJ.
>>
>> Le 18/10/2017, Jérôme BERTHIER<j...@laposte.net> a écrit :
>>
>>> Le 18/10/2017 à 13:29, David Ponzone a écrit :
>>>
>>>> Pour ceux qui ont pas encore vu, grosse faille trouvée dans WPA2.
>>>>
>>>> Mikrotik a corrigé:
>>>> https://forum.mikrotik.com/viewtopic.php?f=21=126695
>>>>
>>>> Meraki aussi:
>>>> https://meraki.cisco.com/blog/2017/10/critical-802-11r-vulne
>>>> rability-disclosed-for-wireless-networks/
>>>>
>>>>
>>>> ---
>>>> Liste de diffusion du FRnOG
>>>> http://www.frnog.org/
>>>>
>>> Salut,
>>>
>>> 9 failles sur 10 sont à corriger côté client semble-t-il.
>>>
>>> ça risque laisser pas mal de monde vulnérable un bon moment...
>>>
>>> Un billet Cisco donne un peu de contexte (et de précisions sur l'impact
>>> de leur côté) :
>>> https://gblogs.cisco.com/fr/zzfeatured/wpa-wpa2-this-is-not-the-end/
>>>
>>> A+
>>>
>>> --
>>> Jérôme BERTHIER
>>>
>>>
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>>
>>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [MISC] Prochains protocoles IP

[Louis]

Bonjour Thomas,

pour IPv8, je souhaiterais le retour aux IP à 4 octets parce que je
n'arrive pas à mémoriser les IPv6. Et puis, des paquets rétro-compatibles
IPv4 et IPv6, parce qu'on a pas de budget pour remplacer tout le matos.

Le 3 mars 2017 à 11:19,  a écrit :

> Bonjour à tous,
>
> Vous le savez, l'IPv4 c'est fini, l'IPv6 c'est en cours, l'IPv8 c'est pour
> bientôt.
>
> Un groupe commence à travailler sur le sujet, notamment Google, Microsoft,
> Amazon, Facebook, Akamai, Cisco, et j'en passe.
>
> J'ai été convié à la discussion, est-ce que vous avez des choses à
> transmettre ?
>
> Thomas
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

Sylvain,

quel est le temps de réponse que tu obtiens? Et quelle taille de window
as-tu lors des transferts?

Le 15 février 2017 à 23:22, <sbu12...@gmail.com> a écrit :

> 100Mb nous sommes en 2017…… en IDF…
>
>
>
> *De :* Ducassou laurent [mailto:laurent.ducas...@spaceshell.fr]
> *Envoyé :* mercredi 15 février 2017 17:52
> *À :* frnog@frnog.org; sbu123fr; Louis
> *Cc :* Liste FRnoG
> *Objet :* Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens
> (MPLS) 500Mo mais plutot 5 x 100Mo
>
>
>
> Totalement cohérent alors.
>
> Le 15 février 2017 17:50:24 GMT+01:00, sbu123fr <sbu12...@gmail.com> a
> écrit :
>
> C ce qu on a fait en "multi session" (-p) nous arrivons à 480 environ en 
> "mono" 100 et des bananes
>
>  Message d'origine 
> De : Louis <luigi.1...@gmail.com>
> Date : 15/02/2017  17:22  (GMT+01:00)
> À : sbu123fr <sbu12...@gmail.com>
> Cc : Ducassou Laurent <laurent.ducas...@spaceshell.fr>, Liste FRnoG 
> <frnog@frnog.org>
> Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 
> x 100Mo
>
> Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est assez 
> fiable. Pas de lecture disque
> Le 15 février 2017 à 17:20, Louis <luigi.1...@gmail.com> a écrit :
> 280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le 
> débit. Avec un transfert multi-session, la tête de lecture/écriture d'un 
> disque classique est obligé de faire en permanence des aller-retours.
> Le 15 février 2017 à 17:07, sbu123fr <sbu12...@gmail.com> a écrit :
> BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo sur 
> la chaîne de liaison
>
>  Message d'origine 
> De : Ducassou Laurent <laurent.ducas...@spaceshell.fr>
> Date : 15/02/2017  16:36  (GMT+01:00)
> À : frnog@frnog.org
> Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
>   100Mo
>
> Plus simplement :
>
> Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS
> 500Mbit/s.
>
> Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est
> que chaque site est relié que avec une fibre optique à 100Mbit/s.
>
> Ca arrive souvent dans les nuages MPLS des DSP ce "problème de
> compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le
> client final crois disposer de 500Mbit/s entre chaque site, mais en
> réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à
> 100Mbit/s sur D et que E est au repos.
>
> Je crois avoir compris cela...
>
>
> Le 15/02/2017 à 15:35, Louis a écrit :
>
>  Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
>  d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
>
>  J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
>
>  "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
>  500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
>  une session TCP entre 2 liens"
>
>
>
>  Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :
>
>  Oui mais non,
>
>  Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
>  liens de façon parfaitement aléatoire, souvent les équipements balancent le
>  trafic de manière *déterministe* sur l'un des liens physiques, en se basant
>  sur le couple adresse source-destination, cela peut-être Adresse IP source
>  / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
>  par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
>  exceptions, et sûrement des solutions propriétaires.
>
>  Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
>  (exception faite des solutions propriétaires ou solutions non déterministes
>  de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
>  100Mbps sur un LAG 5x100Mbps pour un même flux.
>
>  cordialement,
>
>  2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:
>
>  Après quelques recherche, j'arrive à la conclusion que la limitation du
>  temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
>  (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
>  de l'OS.
>
>  L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
>  les (très) vieux OS, la valeur maxi de window size était 65535 octets
>  parce
>  que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
>  1323 est largement utilisée. Elle introduit un paramètre window size
>  scaling factor (8 bits) qui est un multiplcateur de la valeur de window
>  size. Le 

Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est assez
fiable. Pas de lecture disque

Le 15 février 2017 à 17:20, Louis <luigi.1...@gmail.com> a écrit :

> 280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le
> débit. Avec un transfert multi-session, la tête de lecture/écriture d'un
> disque classique est obligé de faire en permanence des aller-retours.
>
> Le 15 février 2017 à 17:07, sbu123fr <sbu12...@gmail.com> a écrit :
>
>> Bonjour
>> Avec du multi session on obtient 280Mo
>> Donc pas de souci de 100Mo sur la chaîne de liaison
>>
>>
>>  Message d'origine 
>> De : Ducassou Laurent <laurent.ducas...@spaceshell.fr>
>> Date : 15/02/2017 16:36 (GMT+01:00)
>> À : frnog@frnog.org
>> Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
>> 100Mo
>>
>> Plus simplement :
>>
>> Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS
>> 500Mbit/s.
>>
>> Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est
>> que chaque site est relié que avec une fibre optique à 100Mbit/s.
>>
>> Ca arrive souvent dans les nuages MPLS des DSP ce "problème de
>> compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le
>> client final crois disposer de 500Mbit/s entre chaque site, mais en
>> réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à
>> 100Mbit/s sur D et que E est au repos.
>>
>> Je crois avoir compris cela...
>>
>>
>> Le 15/02/2017 à 15:35, Louis a écrit :
>> > Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait
>> plus
>> > d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
>> >
>> > J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
>> >
>> > "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
>> > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max
>> sur
>> > une session TCP entre 2 liens"
>> >
>> >
>> >
>> > Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :
>> >
>> >> Oui mais non,
>> >>
>> >> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous
>> les
>> >> liens de façon parfaitement aléatoire, souvent les équipements
>> balancent le
>> >> trafic de manière *déterministe* sur l'un des liens physiques, en se
>> basant
>> >> sur le couple adresse source-destination, cela peut-être Adresse IP
>> source
>> >> / Adresse IP destination, ou de même avec l'adresse MAC, parfois
>> peut-être
>> >> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
>> >> exceptions, et sûrement des solutions propriétaires.
>> >>
>> >> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
>> >> (exception faite des solutions propriétaires ou solutions non
>> déterministes
>> >> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus
>> de
>> >> 100Mbps sur un LAG 5x100Mbps pour un même flux.
>> >>
>> >> cordialement,
>> >>
>> >> 2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:
>> >>
>> >>> Après quelques recherche, j'arrive à la conclusion que la limitation
>> du
>> >>> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
>> >>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des
>> paramètres
>> >>> de l'OS.
>> >>>
>> >>> L'article de 2005 ne précise pas les valeurs de window size
>> utilisées. Sur
>> >>> les (très) vieux OS, la valeur maxi de window size était 65535 octets
>> >>> parce
>> >>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant,
>> la RFC
>> >>> 1323 est largement utilisée. Elle introduit un paramètre window size
>> >>> scaling factor (8 bits) qui est un multiplcateur de la valeur de
>> window
>> >>> size. Le window size est étendu 16Mo au lieu de 64Ko.
>> >>>
>> >>> Calculateur de bande passante sur une session TCP :
>> >>> https://www.switch.ch/network/tools/tcp_throughput/
>> >>> Pour la formule, c'est ici :
>> >>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
>> >>> ghput-for-long-distance-links/
>&

Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le
débit. Avec un transfert multi-session, la tête de lecture/écriture d'un
disque classique est obligé de faire en permanence des aller-retours.

Le 15 février 2017 à 17:07, sbu123fr <sbu12...@gmail.com> a écrit :

> Bonjour
> Avec du multi session on obtient 280Mo
> Donc pas de souci de 100Mo sur la chaîne de liaison
>
>
>  Message d'origine 
> De : Ducassou Laurent <laurent.ducas...@spaceshell.fr>
> Date : 15/02/2017 16:36 (GMT+01:00)
> À : frnog@frnog.org
> Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
> 100Mo
>
> Plus simplement :
>
> Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS
> 500Mbit/s.
>
> Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est
> que chaque site est relié que avec une fibre optique à 100Mbit/s.
>
> Ca arrive souvent dans les nuages MPLS des DSP ce "problème de
> compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le
> client final crois disposer de 500Mbit/s entre chaque site, mais en
> réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à
> 100Mbit/s sur D et que E est au repos.
>
> Je crois avoir compris cela...
>
>
> Le 15/02/2017 à 15:35, Louis a écrit :
> > Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait
> plus
> > d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
> >
> > J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
> >
> > "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
> > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
> > une session TCP entre 2 liens"
> >
> >
> >
> > Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :
> >
> >> Oui mais non,
> >>
> >> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous
> les
> >> liens de façon parfaitement aléatoire, souvent les équipements
> balancent le
> >> trafic de manière *déterministe* sur l'un des liens physiques, en se
> basant
> >> sur le couple adresse source-destination, cela peut-être Adresse IP
> source
> >> / Adresse IP destination, ou de même avec l'adresse MAC, parfois
> peut-être
> >> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
> >> exceptions, et sûrement des solutions propriétaires.
> >>
> >> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
> >> (exception faite des solutions propriétaires ou solutions non
> déterministes
> >> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus
> de
> >> 100Mbps sur un LAG 5x100Mbps pour un même flux.
> >>
> >> cordialement,
> >>
> >> 2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:
> >>
> >>> Après quelques recherche, j'arrive à la conclusion que la limitation du
> >>> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
> >>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des
> paramètres
> >>> de l'OS.
> >>>
> >>> L'article de 2005 ne précise pas les valeurs de window size utilisées.
> Sur
> >>> les (très) vieux OS, la valeur maxi de window size était 65535 octets
> >>> parce
> >>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la
> RFC
> >>> 1323 est largement utilisée. Elle introduit un paramètre window size
> >>> scaling factor (8 bits) qui est un multiplcateur de la valeur de window
> >>> size. Le window size est étendu 16Mo au lieu de 64Ko.
> >>>
> >>> Calculateur de bande passante sur une session TCP :
> >>> https://www.switch.ch/network/tools/tcp_throughput/
> >>> Pour la formule, c'est ici :
> >>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
> >>> ghput-for-long-distance-links/
> >>>
> >>> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s
> max), il
> >>> faudrait une taille window de ~1800 Ko.
> >>>
> >>> Il faut regarder les paramètres de l'OS pour voir si les paramètres
> >>> permettent d'avoir une window de cette taille.
> >>>
> >>> Sur les windows récents, les paramètres sont décrits ici :
> >>> http://www.speedguide.net/articles/windows-8-10-2012-server-
> >>> tcpip-tweaks-5077
> >>> - paragraphe Receive Window 

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.

J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).

"Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
une session TCP entre 2 liens"



Le 15 février 2017 à 15:19, Benjamin Bachelart <b...@bashy.eu> a écrit :

> Oui mais non,
>
> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
> liens de façon parfaitement aléatoire, souvent les équipements balancent le
> trafic de manière *déterministe* sur l'un des liens physiques, en se basant
> sur le couple adresse source-destination, cela peut-être Adresse IP source
> / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
> exceptions, et sûrement des solutions propriétaires.
>
> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
> (exception faite des solutions propriétaires ou solutions non déterministes
> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
> 100Mbps sur un LAG 5x100Mbps pour un même flux.
>
> cordialement,
>
> 2017-02-15 14:56 GMT+01:00 Louis <luigi.1...@gmail.com>:
>
>> Après quelques recherche, j'arrive à la conclusion que la limitation du
>> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
>> de l'OS.
>>
>> L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
>> les (très) vieux OS, la valeur maxi de window size était 65535 octets
>> parce
>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
>> 1323 est largement utilisée. Elle introduit un paramètre window size
>> scaling factor (8 bits) qui est un multiplcateur de la valeur de window
>> size. Le window size est étendu 16Mo au lieu de 64Ko.
>>
>> Calculateur de bande passante sur une session TCP :
>> https://www.switch.ch/network/tools/tcp_throughput/
>> Pour la formule, c'est ici :
>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
>> ghput-for-long-distance-links/
>>
>> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
>> faudrait une taille window de ~1800 Ko.
>>
>> Il faut regarder les paramètres de l'OS pour voir si les paramètres
>> permettent d'avoir une window de cette taille.
>>
>> Sur les windows récents, les paramètres sont décrits ici :
>> http://www.speedguide.net/articles/windows-8-10-2012-server-
>> tcpip-tweaks-5077
>> - paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
>> paramètre est normal.
>>
>> c:\>netsh interface tcp show global
>>
>> Paramètres TCP globaux
>> --
>> État de mise à l'échelle côté réception : enabled
>> État de déchargement Chimney : automatic
>> État NetDMA: enabled
>> Accès direct au cache: disabled
>> *Réglage auto fenêtre de réception   : normal*
>>
>> Malheureusement, je n'ai pas moyen de savoir quelle est la taille de
>> window
>> maxi associée à ce paramètre "normal".
>>
>> Il faudrait tester un téléchargement depuis un windows d'un gros fichier
>> avec une liaison >500 Mbps. Par exemple http://ovh.net/files/1Gio.dat .
>> On
>> verrait quel débit on obtient et Wireshark pourrait donner la taille de
>> window.
>>
>> Louis
>>
>> Le 15 février 2017 à 13:43, Sylvain sbu <sbu12...@gmail.com> a écrit :
>>
>> > 40Kms grand max...
>> >
>> > Le 15 février 2017 à 13:03, Xavier HINFRAY <xhinf...@gmail.com> a
>> écrit :
>> >
>> >> Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière.
>> >> Donc tout dépend de la distance entre le point de départ et d'arrivée.
>> >>
>> >> Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler <
>> >> michel.hostett...@telecom-paristech.fr> a écrit :
>> >>>
>> >>> Bonjour,
>> >>>
>> >>> Est-ce encore plausible de nos jours, un temps d'aller retour de 30
>> ms ?
>> >>>
>> >>> Le document daterait de janvier 2005. Les réseaux n'ont-ils pas
>> évolué depuis 12 ans.
>> >>>
>> >>> Cordialement,
>> >>> Michel
>> >>>
&

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

Après quelques recherche, j'arrive à la conclusion que la limitation du
temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
(comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
de l'OS.

L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
les (très) vieux OS, la valeur maxi de window size était 65535 octets parce
que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
1323 est largement utilisée. Elle introduit un paramètre window size
scaling factor (8 bits) qui est un multiplcateur de la valeur de window
size. Le window size est étendu 16Mo au lieu de 64Ko.

Calculateur de bande passante sur une session TCP :
https://www.switch.ch/network/tools/tcp_throughput/
Pour la formule, c'est ici :
http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/

Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
faudrait une taille window de ~1800 Ko.

Il faut regarder les paramètres de l'OS pour voir si les paramètres
permettent d'avoir une window de cette taille.

Sur les windows récents, les paramètres sont décrits ici :
http://www.speedguide.net/articles/windows-8-10-2012-server-tcpip-tweaks-5077
- paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
paramètre est normal.

c:\>netsh interface tcp show global

Paramètres TCP globaux
--
État de mise à l'échelle côté réception : enabled
État de déchargement Chimney : automatic
État NetDMA: enabled
Accès direct au cache: disabled
*Réglage auto fenêtre de réception   : normal*

Malheureusement, je n'ai pas moyen de savoir quelle est la taille de window
maxi associée à ce paramètre "normal".

Il faudrait tester un téléchargement depuis un windows d'un gros fichier
avec une liaison >500 Mbps. Par exemple http://ovh.net/files/1Gio.dat . On
verrait quel débit on obtient et Wireshark pourrait donner la taille de
window.

Louis

Le 15 février 2017 à 13:43, Sylvain sbu <sbu12...@gmail.com> a écrit :

> 40Kms grand max...
>
> Le 15 février 2017 à 13:03, Xavier HINFRAY <xhinf...@gmail.com> a écrit :
>
>> Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière.
>> Donc tout dépend de la distance entre le point de départ et d'arrivée.
>>
>> Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler <
>> michel.hostett...@telecom-paristech.fr> a écrit :
>>>
>>> Bonjour,
>>>
>>> Est-ce encore plausible de nos jours, un temps d'aller retour de 30 ms ?
>>>
>>> Le document daterait de janvier 2005. Les réseaux n'ont-ils pas évolué 
>>> depuis 12 ans.
>>>
>>> Cordialement,
>>> Michel
>>>
>>> - Mail original -
>>> De: "Louis" <luigi.1...@gmail.com>
>>> À: "sbu123fr" <sbu12...@gmail.com>
>>> Cc: "frnog-tech" <frnog-t...@frnog.org>
>>> Envoyé: Mercredi 15 Février 2017 10:28:06
>>> Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>>>
>>> Probablement oui :
>>>
>>> http://smutz.us/techtips/NetworkLatency.html
>>>
>>> *Round trip latency*
>>>
>>> *TCP Throughput with no packet loss*
>>>
>>> *TCP Throughput with 2% packet loss*
>>>
>>> 0 ms
>>>
>>> 93.50 Mbps
>>>
>>> 3.72 Mbps
>>>
>>> 30 ms
>>>
>>> 16.20 Mbps
>>>
>>> 1.63 Mbps
>>>
>>> 60 ms
>>>
>>> 8.07 Mbps
>>>
>>> 1.33 Mbps
>>>
>>> 90 ms
>>>
>>> 5.32 Mbps
>>>
>>> 0.85 Mbps
>>>
>>> Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput
>>>
>>> Le 14 février 2017 à 18:57, sbu123fr <sbu12...@gmail.com> a écrit :
>>>
>>>  Grand merci.
>>>>  Tu pense que sur des liens en île de france la latence est telle que le
>>>>  trafic peut être divisé par 4-5?
>>>>  Cdt
>>>>  Sbu
>>>>
>>>>
>>>>
>>>>   Message d'origine 
>>>>  De : Louis <luigi.1...@gmail.com>
>>>>  Date : 14/02/2017 18:05 (GMT+01:00)
>>>>  À : Sylvain sbu <sbu12...@gmail.com>
>>>>  Cc : frnog-tech <frnog-t...@frnog.org>
>>>>  Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>>>>
>>>>  cela dépend surtout du temps de réponse sur les liens. On perd en débit à
>>>>  cause des acquittements nécessaires à TCP. Les

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

Probablement oui :

http://smutz.us/techtips/NetworkLatency.html

*Round trip latency*

*TCP Throughput with no packet loss*

*TCP Throughput with 2% packet loss*

0 ms

93.50 Mbps

3.72 Mbps

30 ms

16.20 Mbps

1.63 Mbps

60 ms

8.07 Mbps

1.33 Mbps

90 ms

5.32 Mbps

0.85 Mbps

Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput

Le 14 février 2017 à 18:57, sbu123fr <sbu12...@gmail.com> a écrit :

> Grand merci.
> Tu pense que sur des liens en île de france la latence est telle que le
> trafic peut être divisé par 4-5?
> Cdt
> Sbu
>
>
>
>  Message d'origine 
> De : Louis <luigi.1...@gmail.com>
> Date : 14/02/2017 18:05 (GMT+01:00)
> À : Sylvain sbu <sbu12...@gmail.com>
> Cc : frnog-tech <frnog-t...@frnog.org>
> Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>
> cela dépend surtout du temps de réponse sur les liens. On perd en débit à
> cause des acquittements nécessaires à TCP. Les durées d'acquittement
> s'accroissent avec les temps de réponse. Pendant ce temps là, pas de donnée
> utile ne transite.
>
> Effectivement, un fenêtrage plus haut (window) permet d'améliorer les
> performances en augmentant le nombre de paquets reçus avant acquittements.
> Cela fonctionne bien du moment qu'il n'y a pas de perte sur les liens.
>
> Le fenêtrage est dynamique sur les serveurs en fonction de la qualité de
> la connexion. Les derniers OS ont des valeurs par défaut optimisées mais
> qu'on peut tuner je crois.
>
> L'autre solution est d'optimiser le trafic TCP avec des optimiseurs de
> trafic. Il existe pas mal d'équipements sur le marché qui jouent entre
> autre sur les paramètres window TCP.
>
> Je suppose que le débit est voulu pour des gros transferts de fichier.
> Souvent, la solution adoptée est d'utiliser des outils qui parallélisent le
> transfert du même fichier sur plusieurs sessions TCP.
>
> cordialement,
>
> Louis
>
>
>
>
> Le 14 février 2017 à 16:45, Sylvain sbu <sbu12...@gmail.com> a écrit :
>
>> Bonjour,
>> Non rien a voir avec du hachage car en changeant un paramétrè de
>> "fenêtre" il est possible d'augmenter le max traffic a 75% des 500Mo.
>> cdt
>> SBU
>>
>> Le 14 février 2017 à 16:41, Dominique Rousseau <d.rouss...@nnx.com> a
>> écrit :
>>
>>> Le Tue, Feb 14, 2017 at 04:29:48PM +0100, Sylvain sbu [
>>> sbu12...@gmail.com] a écrit:
>>> > Bonjour,
>>> > Je ne suis pas spécialiste du transport IP.
>>> > Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
>>> > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max
>>> sur
>>> > une session TCP entre 2 liens
>>>
>>> Tes "4 liens", je suppose que c'est "5", avec de l'aggregation.
>>>
>>> La limitation indiquée par ton fournisseur n'est pas étonnante.
>>> Elle correspond aux algorithmes de répartition entre les liens faisant
>>> partie de l'aggregat. Tu peux avoir un "hachage" effectuée sur les
>>> adresses MAC source et destination, par exemple. Ce hachage sert à
>>> "choisir" l'un des liens faisant partie de l'aggregat, et tout le trafic
>>> correspondant a cette meme clef de hachage utilisera le meme lien.
>>> Tut te trouves alors limité par la capacité physique du lien
>>> sélectionné.
>>> Comme tu parles de 5 liens pour obtenir 500Mbps, chacun doit avoir une
>>> capacité de 100Mbps, et donc la limitation s'explique.
>>>
>>>
>>> --
>>> Dominique Rousseau
>>> Neuronnexion, Prestataire Internet & Intranet
>>> 21 rue Frédéric Petit - 8 Amiens
>>> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
>>>
>>>
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>>
>>
>>
>

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

Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

cela dépend surtout du temps de réponse sur les liens. On perd en débit à
cause des acquittements nécessaires à TCP. Les durées d'acquittement
s'accroissent avec les temps de réponse. Pendant ce temps là, pas de donnée
utile ne transite.

Effectivement, un fenêtrage plus haut (window) permet d'améliorer les
performances en augmentant le nombre de paquets reçus avant acquittements.
Cela fonctionne bien du moment qu'il n'y a pas de perte sur les liens.

Le fenêtrage est dynamique sur les serveurs en fonction de la qualité de la
connexion. Les derniers OS ont des valeurs par défaut optimisées mais qu'on
peut tuner je crois.

L'autre solution est d'optimiser le trafic TCP avec des optimiseurs de
trafic. Il existe pas mal d'équipements sur le marché qui jouent entre
autre sur les paramètres window TCP.

Je suppose que le débit est voulu pour des gros transferts de fichier.
Souvent, la solution adoptée est d'utiliser des outils qui parallélisent le
transfert du même fichier sur plusieurs sessions TCP.

cordialement,

Louis




Le 14 février 2017 à 16:45, Sylvain sbu <sbu12...@gmail.com> a écrit :

> Bonjour,
> Non rien a voir avec du hachage car en changeant un paramétrè de "fenêtre"
> il est possible d'augmenter le max traffic a 75% des 500Mo.
> cdt
> SBU
>
> Le 14 février 2017 à 16:41, Dominique Rousseau <d.rouss...@nnx.com> a
> écrit :
>
>> Le Tue, Feb 14, 2017 at 04:29:48PM +0100, Sylvain sbu [sbu12...@gmail.com]
>> a écrit:
>> > Bonjour,
>> > Je ne suis pas spécialiste du transport IP.
>> > Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
>> > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max
>> sur
>> > une session TCP entre 2 liens
>>
>> Tes "4 liens", je suppose que c'est "5", avec de l'aggregation.
>>
>> La limitation indiquée par ton fournisseur n'est pas étonnante.
>> Elle correspond aux algorithmes de répartition entre les liens faisant
>> partie de l'aggregat. Tu peux avoir un "hachage" effectuée sur les
>> adresses MAC source et destination, par exemple. Ce hachage sert à
>> "choisir" l'un des liens faisant partie de l'aggregat, et tout le trafic
>> correspondant a cette meme clef de hachage utilisera le meme lien.
>> Tut te trouves alors limité par la capacité physique du lien
>> sélectionné.
>> Comme tu parles de 5 liens pour obtenir 500Mbps, chacun doit avoir une
>> capacité de 100Mbps, et donc la limitation s'explique.
>>
>>
>> --
>> Dominique Rousseau
>> Neuronnexion, Prestataire Internet & Intranet
>> 21 rue Frédéric Petit - 8 Amiens
>> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>

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

Re: [FRnOG] [FRNOG] [TECH] Fortigate ipsec to Linux server

[Louis]

De mémoire, on peut forcer le proxy-id en cli sur le fortigate.

Le 6 janvier 2017 à 13:21, Servan Jouan  a écrit :

> Bonjour Choukou Moun,
>
> J'ai régulièrement eu des problèmes entre les Fortigate et les autres
> marques. Souvent le problème vient des "proxy-id", il me semble que
> fortigate le calcul automatiquement en fonction des réseaux  "associés" au
> tunnel contrairement aux autres marques ou ils sont explicitement indiqués.
> Ce n'est valable que si tu as plusieurs subnets...
>
> Je ne promets rien, mais c'est une piste ;)
>
> Servan.
>
>
> Le 6 janvier 2017 à 12:30, David Ponzone  a
> écrit :
>
>> Ca, c’est un beau vendredi froid mais ensoleillé qui commence :)
>>
>> > Le 6 janv. 2017 à 12:24, Choukou Moun  a écrit :
>> >
>> > Bonjour à tous
>> >
>> > out d'abord je vous  souhaite  une excellente année 2017 en espérant
>> > qu'elle sera meilleur que cette année 2016.
>> >
>> > J'essai de monter un lien IPsec entre un serveur Linux IPsec et un
>> > Fortigate.
>> >
>> > J'ai l'impression que c'est moi qui a un problème mais je pense que ce
>> > n'est pas possible.
>> >
>> > SI vous avez des pistes je suis preneur merci.
>> >
>> > MAZ
>> >
>> > ---
>> > Liste de diffusion du FRnOG
>> > http://www.frnog.org/
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>
> Le 6 janvier 2017 à 12:30, David Ponzone  a
> écrit :
>
>> Ca, c’est un beau vendredi froid mais ensoleillé qui commence :)
>>
>> > Le 6 janv. 2017 à 12:24, Choukou Moun  a écrit :
>> >
>> > Bonjour à tous
>> >
>> > out d'abord je vous  souhaite  une excellente année 2017 en espérant
>> > qu'elle sera meilleur que cette année 2016.
>> >
>> > J'essai de monter un lien IPsec entre un serveur Linux IPsec et un
>> > Fortigate.
>> >
>> > J'ai l'impression que c'est moi qui a un problème mais je pense que ce
>> > n'est pas possible.
>> >
>> > SI vous avez des pistes je suis preneur merci.
>> >
>> > MAZ
>> >
>> > ---
>> > Liste de diffusion du FRnOG
>> > http://www.frnog.org/
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>

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

Re: [FRnOG] [TECH] Attendre avant de supprimer un prefix BGP de la table de routage en cas de flaping

[Louis]

J'ai testé avec un advertisement-interval à 300s. Le premier update se fait
immédiatement.

Je suppose que les prochains update se feront avec un intervale de 300s.
Seulement, le fait qu'il y ait eu un update de suppression suffit à ce que
la route soit en damping sur le backbone.

Le 24 août 2016 à 14:55, Louis <luigi.1...@gmail.com> a écrit :

> Merci Pierre.
>
> si j'ai bien compris, ce n'est pas prédictif. Si on arrive à la fin de
> l’intervalle, on attends pas 3 min. Ceci-dit, ça vaut le coup de tester
> pour être sûr.
>
>
> Le 24 août 2016 à 14:42, Pierre LANCASTRE <pierre.lancas...@gmail.com> a
> écrit :
>
>> Hello,
>>
>> Je ne sais pas si ça colle au besoin, mais j ai vu sur f5
>> (https://www.google.fr/url?sa=t=web=j=https:/
>> /support.f5.com/kb/en-us/products/big-ip_ltm/manuals/related
>> /bgp-commandreference-7-8-4.pdf=0ahUKEwjn99WTiNrOAhWHl
>> iwKHQILD4wQFggeMAE=AFQjCNH63th7wVaVENMoPcpABC3AvBPsvg&
>> sig2=H-TjVqQEZTfcjJzd2LevAw)
>>
>> neighbor advertisement-interval
>>
>> Use this command to set the minimum interval between the sending of BGP
>> routing updates.  To  reduce the flapping of routes to internet, a minimum
>> advertisement interval is set, so that the BGP routing updates are sent
>> only per interval seconds. BGP dampening can also be used to control the
>> effects of flapping routes.
>>
>> [...]
>>
>> When this parameter is used with a command, the command applies to all
>> peers in the specified group. <0-600> Command Mode Router mode Example
>> Range of values for advertisement-interval, in seconds.
>>
>> ZebOS#configure terminal ZebOS(config)#router bgp 10
>> ZebOS(config-router)#neighbor 10.10.0.3 advertisement-interval 4
>>
>> Cordialement / Best regards
>>
>> Pierre Lancastre
>> Ingénieur Réseaux et Sécurité
>> *-* SENSS - AS59798 *-*
>> /* from my mobile, please ignore typo */
>> +33 7 64 07 26 11
>>
>>
>> Le 24 août 2016 2:29 PM, "Louis" <luigi.1...@gmail.com> a écrit :
>> >
>> > Bonjour,
>> >
>> > j'ai un peering eBGP entre un F5 (qui utilise quagga) et un routeur
>> Juniper
>> > MX. Je souhaiterais que les routes annoncées par le F5 restent dans la
>> > table de routage du MX en cas de flaping. J'ai désactivé le flaping pour
>> > éviter que les routes soient blacklistées mais je cherche un mécanisme
>> pour
>> > attendre 3 min environ avant de supprimer effectivement la route de la
>> > table de routage.
>> >
>> > La raison pour laquelle je cherche à faire cela  est que je ne veux pas
>> > faire de policy sur tout un backbone pour supprimer le damping sur des
>> > prefix venant d'un AS particulier.
>> >
>> > J'ai pensé à :
>> >
>> >- mécanisme de type wait pour attendre 3 min avant d'envoyer
>> >un UPDATE BGP sur le F5
>> >- mécanisme pour garder 3 min la route dans la table de routage sur
>> le
>> >MX après UPDATE BGP
>> >
>> > Evidemment, je n'ai rien trouvé comme commande pour faire cela. Ai-je
>> loupé
>> > qq chose?
>> >
>> > D'autres idées?
>> >
>> > cordialement,
>> >
>> > Louis
>> >
>> > ---
>> > Liste de diffusion du FRnOG
>> > http://www.frnog.org/
>>
>
>

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

Re: [FRnOG] [TECH] Attendre avant de supprimer un prefix BGP de la table de routage en cas de flaping

[Louis]

merci Xavier. Il n'est pas directement relié au F5.

Le 24 août 2016 à 16:45, Xavier Beaudouin  a écrit :

> Hello,
>
> Ceci n'est valable à priori si ton juniper n'est pas connecté directement
> a ton F5, sinon il voit le port down et butte la route associé au peer bgp.
>
> Xavier
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Attendre avant de supprimer un prefix BGP de la table de routage en cas de flaping

[Louis]

Merci Pierre.

si j'ai bien compris, ce n'est pas prédictif. Si on arrive à la fin de
l’intervalle, on attends pas 3 min. Ceci-dit, ça vaut le coup de tester
pour être sûr.


Le 24 août 2016 à 14:42, Pierre LANCASTRE <pierre.lancas...@gmail.com> a
écrit :

> Hello,
>
> Je ne sais pas si ça colle au besoin, mais j ai vu sur f5
> (https://www.google.fr/url?sa=t=web=j=https:/
> /support.f5.com/kb/en-us/products/big-ip_ltm/manuals/
> related/bgp-commandreference-7-8-4.pdf=0ahUKEwjn99WTiNrOAhWHliwKHQILD
> 4wQFggeMAE=AFQjCNH63th7wVaVENMoPcpABC3AvBPsvg=H-
> TjVqQEZTfcjJzd2LevAw)
>
> neighbor advertisement-interval
>
> Use this command to set the minimum interval between the sending of BGP
> routing updates.  To  reduce the flapping of routes to internet, a minimum
> advertisement interval is set, so that the BGP routing updates are sent
> only per interval seconds. BGP dampening can also be used to control the
> effects of flapping routes.
>
> [...]
>
> When this parameter is used with a command, the command applies to all
> peers in the specified group. <0-600> Command Mode Router mode Example
> Range of values for advertisement-interval, in seconds.
>
> ZebOS#configure terminal ZebOS(config)#router bgp 10
> ZebOS(config-router)#neighbor 10.10.0.3 advertisement-interval 4
>
> Cordialement / Best regards
>
> Pierre Lancastre
> Ingénieur Réseaux et Sécurité
> *-* SENSS - AS59798 *-*
> /* from my mobile, please ignore typo */
> +33 7 64 07 26 11
>
>
> Le 24 août 2016 2:29 PM, "Louis" <luigi.1...@gmail.com> a écrit :
> >
> > Bonjour,
> >
> > j'ai un peering eBGP entre un F5 (qui utilise quagga) et un routeur
> Juniper
> > MX. Je souhaiterais que les routes annoncées par le F5 restent dans la
> > table de routage du MX en cas de flaping. J'ai désactivé le flaping pour
> > éviter que les routes soient blacklistées mais je cherche un mécanisme
> pour
> > attendre 3 min environ avant de supprimer effectivement la route de la
> > table de routage.
> >
> > La raison pour laquelle je cherche à faire cela  est que je ne veux pas
> > faire de policy sur tout un backbone pour supprimer le damping sur des
> > prefix venant d'un AS particulier.
> >
> > J'ai pensé à :
> >
> >- mécanisme de type wait pour attendre 3 min avant d'envoyer
> >un UPDATE BGP sur le F5
> >- mécanisme pour garder 3 min la route dans la table de routage sur le
> >MX après UPDATE BGP
> >
> > Evidemment, je n'ai rien trouvé comme commande pour faire cela. Ai-je
> loupé
> > qq chose?
> >
> > D'autres idées?
> >
> > cordialement,
> >
> > Louis
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>

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

[FRnOG] [TECH] Attendre avant de supprimer un prefix BGP de la table de routage en cas de flaping

[Louis]

Bonjour,

j'ai un peering eBGP entre un F5 (qui utilise quagga) et un routeur Juniper
MX. Je souhaiterais que les routes annoncées par le F5 restent dans la
table de routage du MX en cas de flaping. J'ai désactivé le flaping pour
éviter que les routes soient blacklistées mais je cherche un mécanisme pour
attendre 3 min environ avant de supprimer effectivement la route de la
table de routage.

La raison pour laquelle je cherche à faire cela  est que je ne veux pas
faire de policy sur tout un backbone pour supprimer le damping sur des
prefix venant d'un AS particulier.

J'ai pensé à :

   - mécanisme de type wait pour attendre 3 min avant d'envoyer
   un UPDATE BGP sur le F5
   - mécanisme pour garder 3 min la route dans la table de routage sur le
   MX après UPDATE BGP

Evidemment, je n'ai rien trouvé comme commande pour faire cela. Ai-je loupé
qq chose?

D'autres idées?

cordialement,

Louis

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

[FRnOG] [JOBS] Apprentissage Ingénieur

[Franck Louis]

Bonjour à tous,

Je fais passer un CV d'un jeune recherchant un apprentissage pour 3
ans pour un cursus Ingénieur Système/Réseaux.
C'est quelqu'un de motivé, qui sort tout juste d'un DUT Informatique.

Voici le lien pour son CV :
http://www.mediafire.com/download/e996kn5q15mp073/CV_Yassine.pdf

Merci de me contacter directement, et merci pour lui :)

Cordialement


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

Re: [FRnOG] [TECH] Wake On Lan Routage

[Louis]

de mémoire, il faut que le routeur qui porte la gateway du niveau 2 soit
configuré pour router les IPs de broadcast

Le 8 mars 2016 à 13:09, Sylvain Rochet  a écrit :

> Salut Hugo,
>
> On Tue, Mar 08, 2016 at 01:06:36PM +0100, Sylvain Rochet wrote:
> > On Tue, Mar 08, 2016 at 12:02:01PM +, SIMANCAS Hugo wrote:
> > >
> > > Est-ce que le WOL est fonctionnel sur un réseau routé ou la demande
> > > doit forcément venir d'un même réseau L2 ?
> >
> > WOL est fonctionnel sur un réseau routé, c'est de l'UDP/IP.
>
> Plus exactement, avant qu'un pinailleur se réveille ;-), c'est un peu
> tout ce que tu veux, tant que ça arrive sur la machine:
>
> https://en.wikipedia.org/wiki/Wake-on-LAN#Magic_packet
>
> Sylvain
>

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

Re: [FRnOG] Re: [ALERT] Cryptolock

[Louis]

Une question que je me pose : si on paye la rançon, est-ce qu'on récupère
un moyen de déchiffrer les fichiers?


Le 7 mars 2016 à 23:06,  a écrit :

> On lundi 7 mars 2016 18:04:24 CET Sylvain Vallerot - sylv...@gixe.net
> wrote:
> > Bonsoir,
> >
> > On 07/03/2016 17:43, frnog.kap...@antichef.net wrote:
> > > L'éfficacité de l'extorsion par rançongiciel exploite le fait que
> presque
> > > personne ne fait de sauvegarde. Plus les gens feront des sauvegardes et
> > > moins cette attaque sera profitable, Ce qui est encore le meilleur
> moyen
> > > de défense contre ce type d'attaque.
> >
> > Pas vraiment d'accord, si la machine est compromise le rançongiciel est
> > toujours capable de faire des dégâts et de ruiner la productivité d'une
> > personne ou entreprise.
>
> Se servir d'un rançongiciel pour saboter discrètement une entreprise c'est
> une
> utilisation inhabituelle de ce type d'attaque. Pour l'instant l'analyse du
> marché indique que la motivation dérrière les rançongiciels c'est de
> rapporter
> de l'argent, à la fois au programmeur qui le vends et aux escrocs qui s'en
> servent.
>
> Pour ça il faut que les victimes payent la rançon, ce qui n'arrive pas
> quand
> on a une sauvegarde à restaurer. Le sabotage est un effet de bord qui ne
> rapporte pas d'argent en soi et donc n'intéresse pas les opérateurs
> actuels.
>
> Dans tous les cas, avoir des sauvegardes limite les dégats.
>
> Le rançongiciel laisse deux options:
>  1. payer et espérer récupérer ses données
>  2. renoncer à ses données et réinstaller
> Avoir une sauvegarde et un plan d'action prédéfini ça rajoute une troisième
> option:
>  3. restaurer le système et les données les plus récentes
>
> > Suffit d'une toute petite variante pour ça, et
> > une autre variante consistera à menacer d'envoyer tes fichier à tes
> > concurrents ou les publier sur le net. Tes archives ne te protégeront
> > pas de ça.
>
> Chiffrer indistinctement les fichiers d'une machine et identifier les
> fichiers
> ayant de la valeur et de les transférer sur un serveur distant, ce n'est
> pas
> une petite variante, c'est même un tout autre type d'attaque qui existe
> depuis
> bien longtemps, la plus connue étant les numéros de carte bancaires.
>
>
> > La sécurité c'est plusieurs volets : pas seulement la disponibilité des
> > données mais aussi qu'elles soient disponibles au bon moment et pour la
> > bonne personne.
>
> Je parlais quand à moi du volet "quand le désastre est survenu malgré les
> mesures de prévention", c'est à dire quand les données ne sont plus
> disponibles et qu'il faut rétablir tout ça dans un délai le plus court
> possible.
>
> > > C'est le même principe que pour la surveillance globale, plus les
> > > internautes auront recours au chiffrement et plus le coût de cette
> > > surveillance augmente, diminuant de fait son intérêt.
> >
> > Pas d'accord non plus. Quand tout le monde chiffrera ses communications
> > les gouvernements qui le voudront ne cesseront pas de surveiller mais
> > interdiront (comme c'était le cas il y a quelques années encore en France
> > avec la limitation des tailles des clés autorisées) les pratiques de
> > chiffrement qu'ils ne savent pas casser ou contourner. C'est une course
> > que ceux qui disposent de la puissance publique (ou financière)
> gagneront,
> > et donc probablement une erreur pour les autres de l'encourager ou de la
> > hâter puisqu'ils arriveront certainement perdants.
>
> Si tu as suivi un peu l'actualité politique mondiale, les gouvernements
> n'ont
> pas attendu que tout le monde ait recours au chiffrement, ils sont déjà en
> train d'essayer de contrôler le chiffrement.
>
> Le but n'est pas de se débarasser de la surveillance gouvernementale (pour
> ça
> il faudrait se débarasser du gouvernement), il s'agit de réduire la
> surveillance globalisée, tout enregistrer tout le temps, pour revenir a de
> la
> surveillance ciblée.  Il est plus rentable de casser le chiffrement de
> cibles
> définies que de casser le chiffrement de toutes les communications pour en
> extraire celles qui nous intéressent. Un retour à la présomption innocence.
>
> Si tu te souviens du passage de la hadopi, la NSA s'était opposée à cette
> loi
> parce qu'elle risquait de pousser la population a avoir recours au
> chiffrement:
>
> http://www.generation-nt.com/hadopi-cryptologie-service-renseignement-chiffrement-actualite-1094171.html
>
> > Juste mon avis perso.
> >
> > Regards,
> >
> >
> > ---
> > 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] Re: [ALERT] Cryptolock

[Louis]

https://www.gartner.com/doc/339858/signaturebased-virus-detection-desktop-dying
http://blogs.gartner.com/neil_macdonald/2010/12/23/antivirus-is-dead-long-live-antivirus/

Au fait, pour être plus précis, c'est l'antivirus à base de signature qui
est visé par le Gartner. Les antivirus de nos jours intègrent des modes de
détection de comportement et autres... Ces nouveaux algorithmes
ultra-efficaces permettent de supprimer Putty (logiciel suspect) et de
laisser tous les fichiers d'un PC se faire chiffrer par un ransomware
(comportement non suspect).


Le 7 mars 2016 à 17:33, David Ponzone <david.ponz...@gmail.com> a écrit :

> J’ai pas retrouvé l’analyse de Gartner mais leur magic quadrant te donne
> quand même l’impression qu’il faut en installer 5 ou 6 :)
>
> http://www.gartner.com/doc/reprints?id=1-2TXNYBS=151211=sbw
>
>
> > Le 7 mars 2016 à 16:38, Louis <luigi.1...@gmail.com> a écrit :
> >
> > le proxy filtrant ne va pas empêcher la contamination mais a la
> possibilité
> > de filtrer les échanges du virus avec l'extérieur et d'empêcher le
> fishing.
> >
> > Le filtrage dns, c'est qu'une possibilité. Il y a les websense et
> consorts.
> >
> > Quant aux antivirus, on se demande bien à quoi ils servent. Il y a
> > tellement de variantes des malware. Il faut que je retrouve l'article du
> > Gartner qui préconisait d’abandonner les antivirus.
> >
> >
> > Le 7 mars 2016 à 16:13, Stephane Bortzmeyer <bortzme...@nic.fr> a écrit
> :
> >
> >> On Mon, Mar 07, 2016 at 03:12:46PM +0100,
> >> Louis <luigi.1...@gmail.com> wrote
> >> a message of 58 lines which said:
> >>
> >>> Est-ce que vous pensez que comme pour les autres attaques la clé
> >>> privée est commune à tous ou un couple clé privé / publique est
> >>> vraiment générée par PC (comme indiqué dans les messages)?
> >>
> >> Apparemment, oui, la clé est différente par PC. Il y avait un exposé
> >> sur un autre rançongiciel au dernier Botconf
> >> <
> >>
> https://www.botconf.eu/2015/the-story-of-cryptowall-a-historical-analysis-of-a-large-scale-cryptographic-ransomware-threat/
> >>>
> >>
> >>>  - paramétrer dns filtrant d'un éditeur de sécu
> >>
> >> Très mauvaise idée (bricoler un service essentiel de
> >> l'infrastructure).
> >>
> >>>   - pas d'échange en direct sans proxy filtrant
> >> ...
> >>> Ces bonnes pratiques sont à mon avis plus efficaces que n'importe quel
> >>> antivirus
> >>
> >> Et par quel miracle le "proxy filtrant" peut filtrer le contenu
> >> malveillant alors que l'antivirus n'y arrive pas ?
> >>
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

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

Re: [FRnOG] Re: [ALERT] Cryptolock

[Louis]

et encore quand le virus ne désactive l'antivirus.

Le 7 mars 2016 à 16:59, David Ponzone  a écrit :

> Ils protègent des maladies connues et identifiées :)
>
> > Le 7 mars 2016 à 16:55, Xavier Beaudouin  a écrit :
> >
> > Hello,
> >
> >> Quant aux antivirus, on se demande bien à quoi ils servent. Il y a
> >> tellement de variantes des malware. Il faut que je retrouve l'article du
> >> Gartner qui préconisait d’abandonner les antivirus.
> >
> > Ces "antivirus" ne sont qu'une base de signature, qui ont ces signature
> que *après* qu'un virus a été lancé dans le wild.
> >
> > Il n'ont rien a envier aux vaccins dans le monde animal / humain.
> >
> > Ceci dit, beaucoup trop de personnent pense qu'un antivirus protége,
> mais ce n'est jamais le cas.
> >
> > Xavier
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] Re: [ALERT] Cryptolock

[Louis]

le proxy filtrant ne va pas empêcher la contamination mais a la possibilité
de filtrer les échanges du virus avec l'extérieur et d'empêcher le fishing.

Le filtrage dns, c'est qu'une possibilité. Il y a les websense et consorts.

Quant aux antivirus, on se demande bien à quoi ils servent. Il y a
tellement de variantes des malware. Il faut que je retrouve l'article du
Gartner qui préconisait d’abandonner les antivirus.


Le 7 mars 2016 à 16:13, Stephane Bortzmeyer <bortzme...@nic.fr> a écrit :

> On Mon, Mar 07, 2016 at 03:12:46PM +0100,
>  Louis <luigi.1...@gmail.com> wrote
>  a message of 58 lines which said:
>
> > Est-ce que vous pensez que comme pour les autres attaques la clé
> > privée est commune à tous ou un couple clé privé / publique est
> > vraiment générée par PC (comme indiqué dans les messages)?
>
> Apparemment, oui, la clé est différente par PC. Il y avait un exposé
> sur un autre rançongiciel au dernier Botconf
> <
> https://www.botconf.eu/2015/the-story-of-cryptowall-a-historical-analysis-of-a-large-scale-cryptographic-ransomware-threat/
> >
>
> >   - paramétrer dns filtrant d'un éditeur de sécu
>
> Très mauvaise idée (bricoler un service essentiel de
> l'infrastructure).
>
> >- pas d'échange en direct sans proxy filtrant
> ...
> > Ces bonnes pratiques sont à mon avis plus efficaces que n'importe quel
> > antivirus
>
> Et par quel miracle le "proxy filtrant" peut filtrer le contenu
> malveillant alors que l'antivirus n'y arrive pas ?
>

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

Re: [FRnOG] Re: [ALERT] Cryptolock

[Louis]

[troll] la solution : utiliser des applications en mode SaaS sur un PC
linux [/troll]

Troll à part, je pense que ça fait partie des solutions.

Le 7 mars 2016 à 16:27, David Ponzone <david.ponz...@gmail.com> a écrit :

> uTorrent aussi est devenu une saloperie.
> Raison pour laquelle pas mal d’utilisateurs Mac basculent sur qBittorrent.
>
>
> > Le 7 mars 2016 à 16:22, Etienne CorpG <etienne.co...@gmail.com> a écrit
> :
> >
> > Bonjour,
> >
> > Dans le même sujet, un ransomware a aussi été vu dans la version 2.90 du
> client Transmission vendredi dernier:
> http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-ransomware-keranger-infected-transmission-bittorrent-client-installer/
> >
> > Ca impacte les utilisateurs MacOS X.
> >
> > Etienne
> >
> > Le 7 mars 2016 à 16:13, Stephane Bortzmeyer a écrit :
> >
> >> On Mon, Mar 07, 2016 at 03:12:46PM +0100,
> >> Louis <luigi.1...@gmail.com> wrote
> >> a message of 58 lines which said:
> >>
> >>> Est-ce que vous pensez que comme pour les autres attaques la clé
> >>> privée est commune à tous ou un couple clé privé / publique est
> >>> vraiment générée par PC (comme indiqué dans les messages)?
> >>
> >> Apparemment, oui, la clé est différente par PC. Il y avait un exposé
> >> sur un autre rançongiciel au dernier Botconf
> >> <
> https://www.botconf.eu/2015/the-story-of-cryptowall-a-historical-analysis-of-a-large-scale-cryptographic-ransomware-threat/
> >
> >>
> >>> - paramétrer dns filtrant d'un éditeur de sécu
> >>
> >> Très mauvaise idée (bricoler un service essentiel de
> >> l'infrastructure).
> >>
> >>>  - pas d'échange en direct sans proxy filtrant
> >> ...
> >>> Ces bonnes pratiques sont à mon avis plus efficaces que n'importe quel
> >>> antivirus
> >>
> >> Et par quel miracle le "proxy filtrant" peut filtrer le contenu
> >> malveillant alors que l'antivirus n'y arrive pas ?
> >>
> >>
> >> ---
> >> 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] Re: [ALERT] Cryptolock

[Louis]

le fameuse réponse du "work as design". Dernièrement, j'ai eu un "- c'est
pas conforme à la RFC - oui mais c'est work as design. Je demande une
demande de nouvelle fonctionnalité pour changer ça"

Le 7 mars 2016 à 16:03, David Ponzone <david.ponz...@gmail.com> a écrit :

> Non, c’est une ruse qui utilise une « fonctionnalité »  de Microsoft.
> La pièce jointe apparait comme PDF alors que c’est un exe ou zip:
>
> https://en.wikipedia.org/wiki/CryptoLocker#Operation
>
>
> > Le 7 mars 2016 à 15:55, Yannick Guerrini <frnog...@micronity.com> a
> écrit :
> >
> > Il me semble avoir également vu passer du pdf. C'est possible d'ailleurs
> > de lancer automatiquement un script avec ce type de fichier ?
> >
> > Le 07/03/2016 15:21, David Ponzone a écrit :
> >> A priori, le vecteur d’attaque est toujours, jusqu’à nouvel ordre, un
> mail entrant, avec un zip en pièce jointe, qui contient un script qui
> récupère un exe par HTTP.
> >> Pour ma part, j’ai commencé par interdire les pièces jointes contenant
> zip, exe, bat, cmd, msi, etc…. ainsi que le téléchargement de fichiers du
> même type.
> >>
> >>> Le 7 mars 2016 à 15:12, Louis <luigi.1...@gmail.com> a écrit :
> >>>
> >>> c'est effectivement assez inquiétant. J'ai des proches qui se sont
> faits
> >>> avoir. Les fichiers sont chiffrés et prennent l'extension mp3. Pas de
> >>> solution de déchiffrement à jour. Est-ce que vous pensez que comme
> pour les
> >>> autres attaques la clé privée est commune à tous ou un couple clé
> privé /
> >>> publique est vraiment générée par PC (comme indiqué dans les messages)?
> >>>
> >>> Je pense que les bonne pratiques pour limiter le risque de se faire
> >>> infecter :
> >>>
> >>>  - pas d'échange en direct sans proxy filtrant - sauf dérogation de
> flux
> >>>  à ouvrir au cas par cas sur firewall. Règle sur le proxy :
> >>> - interdire de se connecter via une IP sans utiliser des noms dns
> >>> - paramétrer dns filtrant d'un éditeur de sécu
> >>> - autoriser que http-80 et https-443 (interdire CONNECT sur ports
> >>> autres que 443)
> >>>  - désactiver autorun sur tous les PC pour éviter de se faire véroler
> par
> >>>  clé USB
> >>>  - filtre antifishing efficace
> >>>  - (à compléter)
> >>>
> >>> Ces bonnes pratiques sont à mon avis plus efficaces que n'importe quel
> >>> antivirus (qui ne fait en général que ralentir le PC et vous envoyer
> des
> >>> popups). Tous ceux que je connais qui se sont faits infecter avaient un
> >>> antivirus à jour. Un bon virus commence par désactiver l'antivirus.
> >>>
> >>> Le 7 mars 2016 à 14:07, Stephane Bortzmeyer <bortzme...@nic.fr> a
> écrit :
> >>>
> >>>> On Mon, Mar 07, 2016 at 01:51:19PM +0100,
> >>>> David Ponzone <david.ponz...@gmail.com> wrote
> >>>> a message of 8 lines which said:
> >>>>
> >>>>> Quelqu’un a remarqué une forte augmentation des attaques type
> >>>>> cryptolock par mail depuis environ 10 jours ?
> >>>>
> >>>> Blague à part, nos impôts paient une agence qui gère un site Web pour
> >>>> cela (prévenir les citoyens) :
> >>>> http://www.cert.ssi.gouv.fr/site/CERTFR-2016-ALE-001/index.html
> >>>>
> >>>>
> >>>> ---
> >>>> Liste de diffusion du FRnOG
> >>>> http://www.frnog.org/
> >>>>
> >>>
> >>> ---
> >>> Liste de diffusion du FRnOG
> >>> http://www.frnog.org/
> >>
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >>
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] Re: [ALERT] Cryptolock

[Louis]

évidemment faire aussi des sauvegardes et mettre ses archives en read-only
(sans droits pour les remettre en read-write)

Le 7 mars 2016 à 15:12, Louis <luigi.1...@gmail.com> a écrit :

> c'est effectivement assez inquiétant. J'ai des proches qui se sont faits
> avoir. Les fichiers sont chiffrés et prennent l'extension mp3. Pas de
> solution de déchiffrement à jour. Est-ce que vous pensez que comme pour les
> autres attaques la clé privée est commune à tous ou un couple clé privé /
> publique est vraiment générée par PC (comme indiqué dans les messages)?
>
> Je pense que les bonne pratiques pour limiter le risque de se faire
> infecter :
>
>- pas d'échange en direct sans proxy filtrant - sauf dérogation de
>flux à ouvrir au cas par cas sur firewall. Règle sur le proxy :
>   - interdire de se connecter via une IP sans utiliser des noms dns
>   - paramétrer dns filtrant d'un éditeur de sécu
>   - autoriser que http-80 et https-443 (interdire CONNECT sur ports
>   autres que 443)
>- désactiver autorun sur tous les PC pour éviter de se faire véroler
>par clé USB
>- filtre antifishing efficace
>- (à compléter)
>
> Ces bonnes pratiques sont à mon avis plus efficaces que n'importe quel
> antivirus (qui ne fait en général que ralentir le PC et vous envoyer des
> popups). Tous ceux que je connais qui se sont faits infecter avaient un
> antivirus à jour. Un bon virus commence par désactiver l'antivirus.
>
> Le 7 mars 2016 à 14:07, Stephane Bortzmeyer <bortzme...@nic.fr> a écrit :
>
>> On Mon, Mar 07, 2016 at 01:51:19PM +0100,
>>  David Ponzone <david.ponz...@gmail.com> wrote
>>  a message of 8 lines which said:
>>
>> > Quelqu’un a remarqué une forte augmentation des attaques type
>> > cryptolock par mail depuis environ 10 jours ?
>>
>> Blague à part, nos impôts paient une agence qui gère un site Web pour
>> cela (prévenir les citoyens) :
>> http://www.cert.ssi.gouv.fr/site/CERTFR-2016-ALE-001/index.html
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>

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

Re: [FRnOG] Re: [ALERT] Cryptolock

[Louis]

c'est effectivement assez inquiétant. J'ai des proches qui se sont faits
avoir. Les fichiers sont chiffrés et prennent l'extension mp3. Pas de
solution de déchiffrement à jour. Est-ce que vous pensez que comme pour les
autres attaques la clé privée est commune à tous ou un couple clé privé /
publique est vraiment générée par PC (comme indiqué dans les messages)?

Je pense que les bonne pratiques pour limiter le risque de se faire
infecter :

   - pas d'échange en direct sans proxy filtrant - sauf dérogation de flux
   à ouvrir au cas par cas sur firewall. Règle sur le proxy :
  - interdire de se connecter via une IP sans utiliser des noms dns
  - paramétrer dns filtrant d'un éditeur de sécu
  - autoriser que http-80 et https-443 (interdire CONNECT sur ports
  autres que 443)
   - désactiver autorun sur tous les PC pour éviter de se faire véroler par
   clé USB
   - filtre antifishing efficace
   - (à compléter)

Ces bonnes pratiques sont à mon avis plus efficaces que n'importe quel
antivirus (qui ne fait en général que ralentir le PC et vous envoyer des
popups). Tous ceux que je connais qui se sont faits infecter avaient un
antivirus à jour. Un bon virus commence par désactiver l'antivirus.

Le 7 mars 2016 à 14:07, Stephane Bortzmeyer  a écrit :

> On Mon, Mar 07, 2016 at 01:51:19PM +0100,
>  David Ponzone  wrote
>  a message of 8 lines which said:
>
> > Quelqu’un a remarqué une forte augmentation des attaques type
> > cryptolock par mail depuis environ 10 jours ?
>
> Blague à part, nos impôts paient une agence qui gère un site Web pour
> cela (prévenir les citoyens) :
> http://www.cert.ssi.gouv.fr/site/CERTFR-2016-ALE-001/index.html
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Avis sur routeur 3G/4G

[Louis]

Bonjour Sébastien,

j'ai testé le 819 avec différentes versions firmware et IOS. Le résultat
est catastrophique. Mauvaise intégration du module LTE dans l'IOS.
Connections capricieuses au démarrage. Déconnections inexpliquées. En
mobilité, pas de passage entre cellules.

Je ne sais pas si le reste de la gamme cisco vaut mieux mais je te
déconseillerais la marque pour ce besoin.

A la place, on avait pris une marque inconnue au bataillon - j'ai oublié
son nom - mais qui n'avait pas ces défauts.

Louis

Le 4 janvier 2016 à 11:21, Sébastien 65 <sebastien...@live.fr> a écrit :

> Bonjour et meilleurs vœux pour 2016 !!
>
> Je cherche des avis et conseils sur l’acquisition de routeurs 3G/4G.
> J’envisage aussi la possibilité de pouvoir brancher une antenne sur le
> routeur afin d’avoir un meilleur gain…
>
> Que pouvez-vous me conseiller comme gamme de produits et quel est l’ordre
> de prix à peu près ?
>
> J’ai une préférence pour du matos CISCO, je ne connais que le 881 Cellular
> 3G…
>
> Est-ce que le 1841 est possible avec une HWIC LTE (j’ai un doute….) ?
> Le 1921 est-il compatible LTE ?
> Le 819 n'est pas mal, mais son prix est onéreux…
>
> Merci pour votre retour.
>

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

Re: [FRnOG] [TECH] Volkswagen France

[Louis]

j'ai réalisé un logiciel de supervision qui permet d'afficher des SLA à
99.9% de disponibilité en toute circonstance. Peut-être ton client serait
intéressé?



(bon ok je sais on est pas vendredi)

Le 15 décembre 2015 à 14:09, Pierre Emeriaud  a écrit :

> > Je dois connecter plusieurs concessions automobiles au réseau Volkswagen
> > France qui semble un réseau VPN Orange (Business VPN j’imagine).
> >
> > Quelqu’un a-t-il un contact ou connait-il un moyen de s’y connecter par
> un
> > DC quelconque ?
>
> Pourquoi connecter un DC ? tu veux relier les concessions toi-même via
> du celan/c2e/whatever et connecter 1 fois ton DC au lieu d'avoir
> plusieurs spokes sur un bvpn obs ?
>
> Si c'est un DC pour héberger des ressources pour VW, il faut leur
> demander. Si c'est pour connecter des concessions, faut leur demander
> aussi. Même si Orange est concerné, c'est VW qui devra demander à son
> CDP/RSC du compte en question pour la création de nouveaux accès.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Besoin de vos feedback pour très gros projet

[Louis]

je te conseille d'encapsuler l'IP dans du télégramme. C'est plus moderne
que le pigeon voyageur. Avantage : tu n'as pas à gérer ta flotte de pigeon.

http://www.telegramme.com/

Le 15 décembre 2015 à 14:28, Daniel Borloz  a écrit :

> Salut :)
>
> Je te conseille en premier lieu de créer un belle RFC afin que l'on puisse
> bien comprendre les tenants et les aboutissants de ton très gros projet.
>
> Voici un bon exemple de que pourrait être un réseau permettant de
> transmettre une grosse quantité de données de manière ultra-sécurisée:
> https://www.ietf.org/rfc/rfc1149.txt
>
> Il existe même une implémentation avec de la qos:
> http://tools.ietf.org/html/rfc2549
>
> Et une version ipv6: http://tools.ietf.org/html/rfc6214
>
> Bonne lecture.
>
> PS: Non on est pas du tout surveillé ici. C'est une mailing list c'est
> ultra secure par définition :-)
>
> Le 15 décembre 2015 à 13:25, FanThomaS  a écrit :
>
>> Bonjour à tous,
>>
>> Je suis sur un très gros projet qui consiste à créer un réseau TOR "2.0"
>> pour prendre de court nos gouvernements.
>>
>> Par quoi me conseillez-vous de commencer ?
>>
>> Savez-vous où je peux louer des serveurs sans limite de trafic/mois de
>> manière anonyme et à moindre coût ?
>> Une idée de l'OS le plus sécurisé du moment que je pourrais utiliser pour
>> créer tout ça ?
>>
>> Pour de la communication "push" entre serveurs, j'ai pensé à mettre en
>> place un IRC privé, qu'en pensez-vous ?
>>
>> Merci de vos retours,
>> Thomas
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>
>
> --
> Daniel Borloz
> Security Consultant
> CISSP & CISM certified
> Tel: +41 76 301 10 64
>

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

Re: [FRnOG] [TECH] Besoin de vos feedback pour très gros projet

[Louis]

alors là tu te fais des idées.

Je te conseille quand même de chiffrer en IPSEC.

Le 15 décembre 2015 à 14:53, FanThomaS <o...@openaliasbox.org> a écrit :

> J'ai l'impression de ne pas être pris au sérieux :(
>
> Le 2015-12-15 14:45, Louis a écrit :
>
>> je te conseille d'encapsuler l'IP dans du télégramme. C'est plus
>> moderne que le pigeon voyageur. Avantage : tu n'as pas à gérer ta
>> flotte de pigeon.
>>
>> http://www.telegramme.com/ [6]
>>
>> Le 15 décembre 2015 à 14:28, Daniel Borloz <dbor...@x-dan.ch> a
>> écrit :
>>
>> Salut :)
>>>
>>> Je te conseille en premier lieu de créer un belle RFC afin que l'on
>>> puisse bien comprendre les tenants et les aboutissants de ton très
>>> gros projet.
>>>
>>> Voici un bon exemple de que pourrait être un réseau permettant de
>>> transmettre une grosse quantité de données de manière
>>> ultra-sécurisée:https://www.ietf.org/rfc/rfc1149.txt [2]
>>>
>>> Il existe même une implémentation avec de la qos:
>>> http://tools.ietf.org/html/rfc2549 [3]
>>>
>>> Et une version ipv6: http://tools.ietf.org/html/rfc6214 [4]
>>>
>>> Bonne lecture.
>>>
>>> PS: Non on est pas du tout surveillé ici. C'est une mailing list
>>> c'est ultra secure par définition :-)
>>>
>>> Le 15 décembre 2015 à 13:25, FanThomaS <o...@openaliasbox.org> a
>>> écrit :
>>>
>>> Bonjour à tous,
>>>>
>>>> Je suis sur un très gros projet qui consiste à créer un
>>>> réseau TOR "2.0" pour prendre de court nos gouvernements.
>>>>
>>>> Par quoi me conseillez-vous de commencer ?
>>>>
>>>> Savez-vous où je peux louer des serveurs sans limite de
>>>> trafic/mois de manière anonyme et à moindre coût ?
>>>> Une idée de l'OS le plus sécurisé du moment que je pourrais
>>>> utiliser pour créer tout ça ?
>>>>
>>>> Pour de la communication "push" entre serveurs, j'ai pensé à
>>>> mettre en place un IRC privé, qu'en pensez-vous ?
>>>>
>>>> Merci de vos retours,
>>>> Thomas
>>>>
>>>> ---
>>>> Liste de diffusion du FRnOG
>>>> http://www.frnog.org/ [1]
>>>>
>>>
>>> --
>>>
>>> Daniel Borloz
>>> Security Consultant
>>> CISSP & CISM certified
>>> Tel: +41 76 301 10 64 [5]
>>>
>>
>>
>>
>> Links:
>> --
>> [1] http://www.frnog.org/
>> [2] https://www.ietf.org/rfc/rfc1149.txt
>> [3] http://tools.ietf.org/html/rfc2549
>> [4] http://tools.ietf.org/html/rfc6214
>> [5] tel:%2B41%2076%20301%2010%2064
>> [6] http://www.telegramme.com/
>>
>

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

Re: [FRnOG] [TECH] Besoin de vos feedback pour très gros projet

[Louis]

Tu nous auras bien fait rire Fantomas!

Le 15 décembre 2015 à 15:16, Metalman  a écrit :

> Le 15 déc. 2015 à 14:47, FanThomaS  a écrit :
>
> "Aucun document ne correspond aux termes de recherche spécifiés (archive
> frnog o...@openaliasbox.org)."
>
>
> Ouais, alors je m'attendais quand meme a ce que tu reflechisses a propos
> de la vitesse de mise en catalogue de google...
>
> Sans rire :
> https://www.mail-archive.com/frnog@frnog.org/msg36312.html
>
> Et ca juste en retirant l'adresse mail.
>
> Merci du troll, du coup.
> Parce qu'il n'y a plus aucune autre explication possible :'(
> (Serait-ce le frere de jean-kevin ?)
>
> --
> Fabrice BOISSIER
>
>
> Le 2015-12-15 14:37, Metalman a écrit :
>
> Le 15 déc. 2015 à 14:30, FanThomaS  a écrit :
>
> Donc on peut parler sans crainte ??
>
> Je me demande quand est-ce que l'on va avoir le "lol" qui sera ecrit...
>
> Un indice : tape sur google "archive frnog" puis ton mail.
>
> Je t'assure que la securite ca commence par les informations blanches
>
> avant les grises ou noires.
>
> Fabrice BOISSIER
>
> Le 2015-12-15 14:28, Daniel Borloz a écrit :
>
> Salut :)
>
> Je te conseille en premier lieu de créer un belle RFC afin que l'on
>
> puisse bien comprendre les tenants et les aboutissants de ton très
>
> gros projet.
>
> Voici un bon exemple de que pourrait être un réseau permettant de
>
> transmettre une grosse quantité de données de manière
>
> ultra-sécurisée:https://www.ietf.org/rfc/rfc1149.txt [2]
>
> Il existe même une implémentation avec de la qos:
>
> http://tools.ietf.org/html/rfc2549 [3]
>
> Et une version ipv6: http://tools.ietf.org/html/rfc6214 [4]
>
> Bonne lecture.
>
> PS: Non on est pas du tout surveillé ici. C'est une mailing list
>
> c'est ultra secure par définition :-)
>
> Le 15 décembre 2015 à 13:25, FanThomaS  a
>
> écrit :
>
> Bonjour à tous,
>
> Je suis sur un très gros projet qui consiste à créer un réseau
>
> TOR "2.0" pour prendre de court nos gouvernements.
>
> Par quoi me conseillez-vous de commencer ?
>
> Savez-vous où je peux louer des serveurs sans limite de
>
> trafic/mois de manière anonyme et à moindre coût ?
>
> Une idée de l'OS le plus sécurisé du moment que je pourrais
>
> utiliser pour créer tout ça ?
>
> Pour de la communication "push" entre serveurs, j'ai pensé à
>
> mettre en place un IRC privé, qu'en pensez-vous ?
>
> Merci de vos retours,
>
> Thomas
>
> ---
>
> Liste de diffusion du FRnOG
>
> http://www.frnog.org/ [1]
>
> --
>
> Daniel Borloz
>
> Security Consultant
>
> CISSP & CISM certified
>
> Tel: +41 76 301 10 64
>
> Links:
>
> --
>
> [1] http://www.frnog.org/
>
> [2] https://www.ietf.org/rfc/rfc1149.txt
>
> [3] http://tools.ietf.org/html/rfc2549
>
> [4] http://tools.ietf.org/html/rfc6214
>
> ---
>
> Liste de diffusion du FRnOG
>
> http://www.frnog.org/
>
>

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

[FRnOG] [BIZ] Besoin prestation téléphonie Paris VIII

[Louis]

Bonjour,

je cherche une prestation en téléphonie pour un indépendant installé à
Paris VIII.

L'installation actuelle comprend :

   - Ligne analogique avec ADSL
   - Ligne RNIS 2 canaux B et un canal D
   - Plusieurs numéros géographiques contigus associés au RNIS
   - PABX relié au RNIS Siemens HiPath 3250
   - 1 x Téléphone Optiset E (auparavant il y en avait deux mais un est HS)
   - Tout en Orange

Le besoin est de :

   - installation d'un poste dans une pièce supplémentaire (câblage à faire
   en volant ou sans fil)
   - remplacer le poste HS
   - configurer PABX / éventuellement proposer une installation plus
   moderne à base de VoIP
   - 2 appels maxi en simultané
   - conserver transfert d'appel entre postes

merci de me contacter en MP.

cordialement,

Louis

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

[FRnOG] [TECH] Bouquin pour se former sur l'automatisation réseau

[Louis]

Bonjour la mailing-list,

je recherche un bouquin pour se former sur l'automatisation réseau : techno
NETCONF, PYTHON, ANSIBLE et j'en passe.

Le but est de mettre en place de l'automatisation de configuration normée
(toujours identiques aux descriptions de ports, vlans et IP près).

Vous avez des idées?

Merci d'avance.

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

Re: [FRnOG] [JOBS] Candidature Admin sys

[Louis]

salut Ronan,

> elle c'est transformé

elle s'est transformée non?

http://bescherelletamere.fr/ne-les-oublions-pas/

Le 23 septembre 2015 12:21, Ronan Ducamp  a écrit :

> Oops, je n'avais pas vu que je répondais au mail perso directement.
>
> Vous n'avez pas vu mes excuses, ni les raisons de mes fautes.
>
> Bref merci a tous de votre soutien, dois-je recommencer ma candidature car
> là elle c'est transformé en débat..
>
> Le 23 septembre 2015 12:15, Xavier ROCA  a écrit :
>
>> Lai jêny son null an ortograf !
>>
>> ;) Xavier
>>
>> -Message d'origine-
>> De : Eric ROLLAND [mailto:roll...@artefact.fr]
>> Envoyé : mercredi 23 septembre 2015 11:58
>> À : frnog@frnog.org
>> Objet : Re: [FRnOG] [JOBS] Candidature Admin sys
>>
>> Le 23/09/2015 11:44, David Ponzone a écrit :
>> > Ouais enfin, quand une fois salarié, on publie sur une ML ou ailleurs,
>> on
>> représente la société.
>> > Si on peut pas faire un effort avant d’être embauché, on en fera pas
>> après. C’est même généralement pire.
>>
>>
>> Bonjour,
>> Pas d'accord avec ca. J'ai un collègue adminsys qui a beau se relire, il
>> en
>> laisse quand même, et pourtant il fait un vrai effort.
>> Après, lorsque j'en vois passer une, je lui signale et ca fait progresser.
>> Et c'est pareil pour moi, mais je ne reprends pas un message sur la ML
>> parcequ'il est truffé de fautes.
>> Enfin, on a un client qui passe des tickets de 5 mots avec 7 fautes. Et
>> alors ? On va pas le jeter parce qu'il fait des fautes d'orthographe.;-)
>> Cordialement, Eric ROLLAND
>> AS42929 - RE515-RIPE
>>
>> 
>> *Artefact communication interactive* | Bat. Artechnopole - 3 rue des
>> Frères
>> Goncourt - 19100 BRIVE | Tel 0555 17 29 29 | Fax 0957 33 00 33 SARL au
>> capital de 50.000 Euros - RCS BRIVE 444 110 936 | NAF 7311Z | TVA Intracom
>> FR87444110936 | ORG-ARTE2-RIPE - PGPKEY-32DDEF07 Info réseau :
>> @NocArtefact
>>  - NOC Artewan > >
>>
>> *artefact
>> *Communication Interactive
>> www.artefact.fr *artewan*
>> Opérateur de réseaux et de services
>> www.artewan.fr   *arteone*
>> Datacenter, Informatique & Services IT
>> www.arteone.fr 
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>
>
> --
> Ronan DUCAMP
>

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

Re: [FRnOG] [TECH] Hôte pointant vers 127.0.0.1

[Louis]

dis moi ton client, il n'est pas sur la liste? Parce que si oui, tu as plus
besoin de poser la question ;-)

Le 23 septembre 2015 16:50, Julien Escario  a écrit :

> Le 23/09/2015 16:42, David Ponzone a écrit :
> > Sincèrement, j’ai du mal à voir le problème.
> >
> > Il veut un:
> >
> > dev.monsitealacon.com IN  A   127.0.0.1
> >
> >  parce qu’il a du mal à tester son site en tapant:
> >
> > http://127.0.0.1/
> >
> > ?
> >
> > Ben fais lui son A, avec un écrit de sa part au cas où un jour il se
> mettre à nier t’avoir demandé ça.
>
> Ouais en fait, ce n'est pas tout à fait ça. Il veut
> local.mondomainedefeignasse.com (oui le ndd est long) pour tester en
> local et
> basculer plus tard sur www.mondomainedefeignasse.com ce qui, au final,
> est une
> connerie totale puisqu'il va de toute façon devoir changer le hostname
> dans son
> CMS ...
>
> Ce qu'il ne veut pas, c'est dev sur
> http://localhost/monfuturdomainedefeignasse.com
>
> Ca, je peux comprendre mais pourquoi pas un bête fichier host et il
> n'emmerde
> pas le sysadmin que je suis ? Si je dis oui, je vais l'avoir sur le dos
> pour ces
> conneries à chaque dev ? Bref, il faut que je tranche. Ou alors je retarde
> jusqu'à ce qu'il comprenne que c'est plus rapide si il se prend en main.
>
> Tiens, oui, je vais faire ça.
>
> Julien
>
>

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

Re: [FRnOG] [TECH] [réseau GSM] Petit coup de main

[Louis]

Jérémy,

par curiosité, ton client a -t'il pensé à expérimenter les réseaux mobiles
pour objets connectés comme LoRa et Sigfox? Je ne suis pas sûr que ces
technos soient encore très matures ceci-dit.

Le 21 septembre 2015 16:11, Armel Chargé - frekences <ar...@frekences.com>
a écrit :

> Le projet OpenBTS permet de créer son propre réseau :
> http://openbts.org/
>
> Par contre, nous sommes loin des systèmes en production par nos opérateurs
> nationaux ( puissance / capacité d’accueil ).
>
>
>
>
> Le 21 septembre 2015 à 16:06:23, Louis (luigi.1...@gmail.com) a écrit:
>
> Ca a l'air plutôt intéressant comme projet. Créer un réseau mobile, on n'a
> pas l'occasion de le faire tous les jours.
>
> >Faudra juste construire une grande cage de faraday autour du périmètre :)
>
> >Ceci dit, il doit y avoir moyen de baisser la puissance des BTS, mais on
> est alors plus dans une situation réaliste.
> >Et si tu baisses pas la puissance, tu n’es toujours pas une situation
> réaliste car tu es rarement aussi bien placé de la BTS avec un signal
> aussi
> clean.
>
> J'imagine qu'il y a possibilité d'avoir des fréquences de test dédiées
> autres que celles des opérateurs nationaux pour éviter ce problème. Par
> exemple, GSM-R (sorte de GSM pour le rail) a obtenu ses propres fréquences
> https://fr.wikipedia.org/wiki/GSM-R
>
> Louis
>
> Le 21 septembre 2015 15:49, Jeremy <li...@freeheberg.com> a écrit :
>
> > Le centre de recherche veut une indépendance totale pour mesurer
> notamment
> > les effets de la perte de signal sur les véhicules.
> > Le but étant de pouvoir moduler la puissance d’émission du max autorisé
> au
> > minimum possible afin de faire beaucoup de mesures dans l'air, et dans
> les
> > véhicules en mouvement.
> >
> > Je suis pas sur qu'un opérateur privé acceptera de moduler la puissance
> > d’émission ou de laisser la main sur le coeur de réseau justement :)
> >
> > Jérémy
> >
> >
> > Le 21/09/2015 15:36, Xavier HINFRAY a écrit :
> >
> >> Pourquoi ne pas demander a un orange/sfr/bouygues de te poser une
> antenne
> >> en offre sur mesure pour entreprise. Ca te couterait sans doute moins
> >> chère, et ca sera "comme dans le commerce" ? Car déployé les 3
> technologies
> >> ca va coutez bonbon si tu vises a etre proche des operateurs... il n'y
> a
> >> pas que les antennes a mettre mais tout le coeur de reseau !
> >>
> >> Ps : je n'ai pas mit free car il ne me semble pas qu'il fasse des osm
> >> entreprise.
> >>
> >> Le 21 septembre 2015 14:40:08 GMT+02:00, Jeremy <li...@freeheberg.com>
> a
> >> écrit :
> >>
> >>> Salut les barbus,
> >>>
> >>> J'ai un centre de recherche voisin qui m'a contacté car ils veulent
> >>> qu'on leur chiffre la construction d'un réseau GSM privé sur un centre
> >>> de recherche (2.5 ha), en 2G/3G/4G dans le but d'expérimenter des
> >>> voitures autonomes.
> >>> Le but est de vérifier que le réseau qui sera en place soit le plus
> >>> similaire à un réseau d'opérateur privé. Il va donc falloir utiliser
> >>> des
> >>> fréquences compatibles avec les devices que l'on trouve dans le
> >>> commerce.
> >>>
> >>> Du coup, comme on est sur un cas très spécifique ou il faut chiffrer
> la
> >>>
> >>> pose d'antennes, d'équipements, et de l'utilisation de fréquences déjà
> >>> attribuées, je suppose que l'ARCEP peut éventuellement donner un
> accord
> >>>
> >>> d'utilisation dans des conditions très précises.
> >>>
> >>> Comme on a jamais fait ça (toute la partie GC, pose d'équipements,
> >>> config, on maitrise), je voulais savoir comment vous procèderiez pour
> >>> monter ce chiffrage (et le projet si budget ok), notamment d'un point
> >>> de
> >>> vue administratif ?
> >>>
> >>> Merci pour le coup de main !
> >>>
> >>> Jérémy
> >>>
> >>> __
> >>> FreeHeberg.com : Osez l'h�bergement gratuit de qualit� professionnelle
> >>> !
> >>> PHP + Mysql + Espace 2 � 20 Go
> >>>
> >>>
> >>> ---
> >>> Liste de diffusion du FRnOG
> >>> http://www.frnog.org/
> >>>
> >>
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

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

Re: [FRnOG] [TECH] [réseau GSM] Petit coup de main

[Louis]

Ca a l'air plutôt intéressant comme projet. Créer un réseau mobile, on n'a
pas l'occasion de le faire tous les jours.

>Faudra juste construire une grande cage de faraday autour du périmètre :)

>Ceci dit, il doit y avoir moyen de baisser la puissance des BTS, mais on
est alors plus dans une situation réaliste.
>Et si tu baisses pas la puissance, tu n’es toujours pas une situation
réaliste car tu es rarement aussi bien placé de la BTS avec un signal aussi
clean.

J'imagine qu'il y a possibilité d'avoir des fréquences de test dédiées
autres que celles des opérateurs nationaux pour éviter ce problème. Par
exemple, GSM-R (sorte de GSM pour le rail) a obtenu ses propres fréquences
https://fr.wikipedia.org/wiki/GSM-R

Louis

Le 21 septembre 2015 15:49, Jeremy <li...@freeheberg.com> a écrit :

> Le centre de recherche veut une indépendance totale pour mesurer notamment
> les effets de la perte de signal sur les véhicules.
> Le but étant de pouvoir moduler la puissance d’émission du max autorisé au
> minimum possible afin de faire beaucoup de mesures dans l'air, et dans les
> véhicules en mouvement.
>
> Je suis pas sur qu'un opérateur privé acceptera de moduler la puissance
> d’émission ou de laisser la main sur le coeur de réseau justement :)
>
> Jérémy
>
>
> Le 21/09/2015 15:36, Xavier HINFRAY a écrit :
>
>> Pourquoi ne pas demander a un orange/sfr/bouygues de te poser une antenne
>> en offre sur mesure pour entreprise. Ca te couterait sans doute moins
>> chère, et ca sera "comme dans le commerce" ? Car déployé les 3 technologies
>> ca va coutez bonbon si tu vises a etre proche des operateurs... il n'y a
>> pas que les antennes a mettre mais tout le coeur de reseau !
>>
>> Ps : je n'ai pas mit free car il ne me semble pas qu'il fasse des osm
>> entreprise.
>>
>> Le 21 septembre 2015 14:40:08 GMT+02:00, Jeremy <li...@freeheberg.com> a
>> écrit :
>>
>>> Salut les barbus,
>>>
>>> J'ai un centre de recherche voisin qui m'a contacté car ils veulent
>>> qu'on leur chiffre la construction d'un réseau GSM privé sur un centre
>>> de recherche (2.5 ha), en 2G/3G/4G dans le but d'expérimenter des
>>> voitures autonomes.
>>> Le but est de vérifier que le réseau qui sera en place soit le plus
>>> similaire à un réseau d'opérateur privé. Il va donc falloir utiliser
>>> des
>>> fréquences compatibles avec les devices que l'on trouve dans le
>>> commerce.
>>>
>>> Du coup, comme on est sur un cas très spécifique ou il faut chiffrer la
>>>
>>> pose d'antennes, d'équipements, et de l'utilisation de fréquences déjà
>>> attribuées, je suppose que l'ARCEP peut éventuellement donner un accord
>>>
>>> d'utilisation dans des conditions très précises.
>>>
>>> Comme on a jamais fait ça (toute la partie GC, pose d'équipements,
>>> config, on maitrise), je voulais savoir comment vous procèderiez pour
>>> monter ce chiffrage (et le projet si budget ok), notamment d'un point
>>> de
>>> vue administratif ?
>>>
>>> Merci pour le coup de main !
>>>
>>> Jérémy
>>>
>>> __
>>> FreeHeberg.com : Osez l'h�bergement gratuit de qualit� professionnelle
>>> !
>>> PHP + Mysql + Espace 2 � 20 Go
>>>
>>>
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>>
>>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Ip d'interco bgp

[Louis]

> Plus propre : à ma connaissance, rien n'interdit d'établir un peer BGP en
ipv6 pour annoncer des routes en v4.

Je ne comprends pas. Ca fait une next-hop d'un subnet ipv4 en ipv6? Ca
marche vraiment?

Louis

Le 15 septembre 2015 08:16, Julien Escario <esca...@azylog.net> a écrit :

> Le 15/09/2015 00:51, Frederic Dhieux a écrit :
>
>>
>>
>> Le 14/09/2015 22:12, Raphael Mazelier a écrit :
>>
>>>
>>>
>>> J'ai pas dit que cela devait être forcement le cas en nominal, certain
>>> le font (jaguar de souvenir), d'autre (moi le premier) non. En
>>> revanche avoir un /24 en stock qui peut servir en cas de besoin, et le
>>> dédier temporairement à tel ou tel besoin c'est quand même bien
>>> pratique. (surtout quand il s'agit de dépanner un client).
>>>
>>>
>> C'est moche et ça va faire râler du monde, mais au pire dans l'urgence
>> de la situation prendre un subnet d'interco dans RFC1918 c'est peut-être
>> un moindre mal le temps de trouver une solution plus propre et pérenne.
>>
>> Frédéric
>>
>
> C'est aussi la solution qui m'est venue à l'esprit.
>
> Plus crade : jouer avec des ips dans la plage 127.0.0.0/24 pour établir
> la session BGP. J'ignore si c'est possible mais ça retournerait l'attaque.
>
> Plus propre : à ma connaissance, rien n'interdit d'établir un peer BGP en
> ipv6 pour annoncer des routes en v4.
>
> Le pourcentage du botnet ayant un stack ipv6 devant être quasi négligeable
> (désolé les gars), ça doit au minimum fortement diminuer l'attaque voir la
> stopper.
>
> Et la dernière en guise d'hypothèse : faire mentir les réponses ICMP ou
> tout simplement filtrer l'ICMP AVANT de changer l'ip d'interco (pour les
> autres hosts que le routeur en face bien entendu).
> A ma connaissance, rien n'interdit de mettre de la merde dans le reply
> ICMP, ca arrivera quand même.
> Du coup, le mec va voir rien ou n'importe quoi quand il fera son
> traceroute pour trouver ton IP d'interco.
>
> Des solutions en vrac, rien de testé bien entendu ...
>
> Julien
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Ip d'interco bgp

[Louis]

en même temps ça sert à quoi d'annoncer des intercos à l'extérieur?

Le 15 septembre 2015 13:35, Jérôme BERTHIER  a écrit :

> Le 15/09/2015 13:13, David Touitou a écrit :
>
>> Question certainement idiote : quelle différence par rapport à utiliser
>> des RFC1918 ?
>>
> La réversibilité ?
>
> Les attaquants passeront bien à une autre cible et il sera alors possible
> de ré-annoncer les intercos ?
>
> --
> Jérôme BERTHIER
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [MISC] Lancement de la première fibre en 56K pour nostalgeeks

[Louis]

Bonne pause!

http://www.legorafi.fr/2015/08/25/lancement-de-la-premiere-fibre-en-56k-pour-nostalgeeks

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

Re: [FRnOG] [TECH] Pb Cisco xconnect sur MPLS sur QinQ

[Louis]

Bonjour,

il doit y avoir des chances pour que tu ais des paquets qui sortent en tag
2002+106 côté PEB et 2004+3057, côté PEA. Tu as moyen de faire des captures
wireshark?

Tu pourrais tester avec un tag interne à 106?

PE#A
interface GigabitEthernet0/0/2.2004106
 description Cross-Co_to_Site_ClientB
 encapsulation dot1Q 2004 second-dot1q *106*
 xconnect 10.10.10.67 100 encapsulation mpls
!

PE#B
interface GigabitEthernet0/0/2.20023057
 description Cross-Co_to_Site_ClientA
 encapsulation dot1Q 2002 second-dot1q *106*
 xconnect 10.10.10.66 100 encapsulation mpls

En général, QnQ ce n'est pas conseillé à cause des MACs virtuelles qui
peuvent entraîner du mac flapping. Mais je suppose que tu posterais pas si
tu avais moyen de revoir cela.

cordialement,

Louis

Le 2 juillet 2015 10:30, Marc SALVI marc.salvi@gmail.com a écrit :

 Bonjour à tous,

 Je fais face à un souci d'implémentation Cisco qui m'a causé bien des
 déboires.
 La problématique en une phrase: La fonctionnalité xconnect de Layer2 sur
 MPLS sur QinQ ne marche pas.

 Pour présenter mon problème, voilà le setup:

  - 2 routeurs PE Cisco ASR1001x distant (sur 2 DC, ils pourraient être dans
 la meme baie, c'est pareil )
  - Les 2 PE sont reliés entre eux par une fibre: Ils partagent les
 fonctionnalités: ISIS/BGP/MPLS/LDP/etc : Pas de soucis de ce coté
  - Chaque PE est raccordé à une fibre d'acces client, sur laquelle ils
 doivent décapsuler des vlans provenant d'un QinQ: pas de problème sur le
 principe.

 Contexte présentant la problématique :

  - Lorsque je veux abouter 1 vlan précis d'une fibre client arrivant sur le
 PE#A et un autre vlan du PE#B, et bien les 2 sites clients ne communiquent
 pas.
  - Au niveau backbone le xconnect est bien etabli pas de souci.
  - Même si les 2 vlans en QinQ arrivent sur le même PE avec une connexion
 de
 vlan en local (donc sans MPLS), cela ne fonctionne pas non plus.

 Work around appliqué:
   - Lorsque l'on supprime le QinQ est que l'on fait arriver les vlans en
 simple tag (1 seul niveau de vlan) sur les PE, tout fonctionne bien.

 Avez-vous déjà été confronté à ce type d'implémentation xconnect ? Est-ce
 un
 bug Cisco?
 Merci de votre retour

Marc

 A titre indicatif, voilà la config des PE:

 == PE#A

 OS: asr1001x-universalk9.03.13.02.S.154-3.S2-ext.SPA.bin

 PE#A
 interface GigabitEthernet0/0/2.2004106
  description Cross-Co_to_Site_ClientB
  encapsulation dot1Q 2004 second-dot1q 106
  xconnect 10.10.10.67 100 encapsulation mpls
 !

 PE#B
 interface GigabitEthernet0/0/2.20023057
  description Cross-Co_to_Site_ClientA
  encapsulation dot1Q 2002 second-dot1q 3057
  xconnect 10.10.10.66 100 encapsulation mpls



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


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

[FRnOG] [TECH] SDN chez Google

[Louis]

un article plutôt intéressant

http://www.reseaux-telecoms.net/actualites/lire-google-explique-pourquoi-il-a-ete-oblige-de-construire-ses-propres-reseaux-27365.html?utm_source=mailutm_medium=emailutm_campaign=Newsletter

Il y a aussi une keynote que je regarderai quand j'aurai un peu de temps
https://www.youtube.com/watch?v=n4gOZrUwWmc

Louis

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

Re: Fwd: [FRnOG] [JOBS] Coupure de connexion SSH

[Louis]

Bonjour Mehdi,

si jamais il s'avère que le nexus soit en cause, pourras-tu nous partager
la release en cause et celle qui la corrige?

Merci

Le 26 mai 2015 16:05, Mehdi BADAOUI mehdiu...@gmail.com a écrit :

 Merci pour ta réponse Jérôme,

 je vais vérifier ça.

 Cordialement,

 Le 26 mai 2015 15:46, Jérôme BERTHIER j...@laposte.net a écrit :

 Salut,

 Tu as des CRC dans tes compteurs ?

 Si oui, petite subtilité Nexus (au moins valable pour les 5500).
 Ils fonctionnent en mode cut-through. Les erreurs ne sont pas
 comptabilisées en ingress mais en egress. Le switch fait suivre la trame
 pourrie avec un flag FCS modifié pour alerter l'hôte destinataire (ou le
 prochain switch capable de dropper en mode store and forward).

 Si tu veux voir où ça se dégrade, faut creuser un peu dans les compteurs
 internes. Exemple sur N5K : show hardware internal carmel crc :

 http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/troubleshooting/guide/N5K_Troubleshooting_Guide/n5K_ts_l2.html#99218

 J'ai eu le cas entre deux salles reliées par des Nexus 5000. Un port
 Nexus reliant un pare-feu s'est mis à incrémenter des erreurs CRC. Au
 final, c'était un SFP d'un autre port entre les deux salles qui était
 pourri : les nexus forwardaient en l'état les trames erronées.

 Bon courage


 Le 26/05/2015 14:44, Mehdi BADAOUI a écrit :

 Hello All,

 Après un long week-end retour sur le problème :)

 Apparemment l'erreur viens du Nexus et pas de mon serveur, ce matin mon
 deuxième serveur commence à être impacté avec 5% de perte de paquet.
 On a constaté ce matin que y a une perte de paquet sur les deux Nexus
 3548P
 alors la solution qu'on a pour le moment est de faire un upgrade des
 Nexus

 Est ce que y a d'autres propositions?

 Cordialement,

 -- Message transféré --
 De : Mehdi BADAOUI mehdiu...@gmail.com
 Date : 22 mai 2015 09:10
 Objet : Re: [FRnOG] [JOBS] Coupure de connexion SSH
 À : David Ponzone david.ponz...@gmail.com


 Merci à vous tous,

 Mehdi



 Le 21 mai 2015 18:14, David Ponzone david.ponz...@gmail.com a écrit :

  +1

 Faut régler le problème de pertes de paquet, qui est plus qu’anormal sur
 un LAN.

 Dans l’ordre de probabilité décroissante:
 -défaut sur l’OS (si OS=windows) (ok je sors)
 -problème d’autonégo
 -défaut de câble
 -défaut de carte réseau
 -défaut sur l’OS (si OS=linux)
 -pas de chance
 -défaut sur Nexus

 Le 21 mai 2015 à 14:12, Alexis Lameire alexis.lame...@gmail.com a
 écrit
 :

  j'ai vue passé un truc similaire sur cette ml il y a quelque temps de
 ca.

 Envois nous un ptit ifconfig de l'interface de ton serveur, savoir si
 il
 est en 1G ou 100M (soucis d'auto nego, toussa toussa).

 Cordialement
 Alexis Lameire

 Le 21 mai 2015 14:08, Thomas Dubois thomas.f.dub...@gmail.com a
 écrit

 :

 Et pourquoi le sujet est à propos de SSH alors que c'est un problème de
 Layer 2?

  Quand tu fais des traceroutes, tu passes par le même chemin pour les
 2

 serveurs ?
 Le TTL est de 63 sur le ping donc la machine est connectée sur le même
 réseau.

 Thomas D.

 Le 21 mai 2015 13:56, Jeremy li...@freeheberg.com a écrit :

  Pourquoi ce mail atterrit sur la boite JOBS ? ...

 Jérémy

 Le 21/05/2015 13:36, Mehdi BADAOUI a écrit :

  Bonjour la liste,

 J'ai deux serveurs reliés à un même Vlan, le Vlan est connecté à un
 routeur
 Nexus.
 Un des deux serveurs a des coupures fréquentes de connexion ssh et
 pas

 le

 deuxième.
 Je précise que les deux serveurs ne passe pas par un FireWall.

 Résultat d'un Ping d'une machine X vers le serveur en question.

 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Délai d'attente de la demande dépassé.
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps=1 ms TTL=63
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Délai d'attente de la demande dépassé.
 Délai d'attente de la demande dépassé.
 Réponse de 192.168.130.5 : octets=32 temps1ms TTL=63
 Délai d'attente de la demande dépassé.
 Délai d'attente de la demande dépassé.
 Délai d'attente de la demande dépassé.
 Délai d'attente de la demande dépassé.
 Délai d'attente de la 

Re: [FRnOG] [ALERT] Problème ligne Completel

[Louis]

si c'est du câble, alors la terminaison est coaxiale. NC/completel ne fait
pas de conversion coaxial vers fibre.


Le 19 mai 2015 16:31, Jean-Baptiste jbfa...@gmail.com a écrit :

 Pour être honnête, je ne sais pas exactement, j'ai bien une fibre qui
 arrive, ce qu'il y a avant je ne le sais pas.
 Y a t-il un moyen simple de le vérifier ?

 Merci.

 Le 19 mai 2015 16:25, David Ponzone david.ponz...@gmail.com a écrit :

 T’es sûr que c’est une fibre ?
 C’est pas du câble NC que Completel revend comme FTTH ? :)


 Le 19 mai 2015 à 16:22, Jean-Baptiste jbfa...@gmail.com a écrit :

  @David, je te laisse imaginer que non ;-) sinon je ne posterai pas sur
 nOG
  @Fathia, effectivement je confirme le rétablissement vers 14h, merci
 pour
  le retour. En revanche, nous n'avons pas eu le privilège d'avoir la même
  notice à propos de la collecte...
 
  Cheers
 
  Le 19 mai 2015 15:48, fatiha boudj fbo...@yahoo.fr a écrit :
 
  Nous avons rencontre le meme probleme avec nos clients dans le 11e
  retablissement vers 14h
  ci dessous retour Completel
 
  Notre diagnostique nous indique un défaut sur notre équipement de
  collecte de la fibre sur notre tête de réseau vers le client.
  Nous déclenchons une intervention afin d'effectuer un remplacement de
 la
  SFP de la fibre.
  Nous vous tiendrons informé sur la planification de cette
 intervention.
 
 
   --
  *De :* Jean-Baptiste jbfa...@gmail.com
  *À :* frnog@frnog.org
  *Envoyé le :* Mardi 19 mai 2015 10h22
  *Objet :* [FRnOG] [ALERT] Problème ligne Completel
 
  Bonjour,
 
  J'ai depuis ce matin un problème sur mon accès Completel (FTTH / Paris
  11ème), pas moyen de récupérer d'IP.
  Completel indique un problème obscur avec un presta et un
 rétablissement
  approximatif dans quelques heures au plus (une perle).
 
  Si quelqu'un à plus d'infos à ce sujet, je suis preneur, mieux, si
  quelqu'un de Completel lis ce mail, un petit UP sur le status serait le
  bienvenu.
 
  Cheers
 
  -- JB
 
  ---
  Liste de diffusion du FRnOG
  http://www.frnog.org/
 
 
 
 
  -- JB
 
  ---
  Liste de diffusion du FRnOG
  http://www.frnog.org/




 --

 Jean-Baptiste FAREZ

 6 Bis, Rue de Pierrepont
 80134 Hangest en Santerre

 Tél : +33 (0)3 22 35 33 91
 Gsm : +33 (0)6 51 39 67 87

 jbfa...@gmail.com

 --

 LinkedIn : http://minu.me/-jbfldn
 Viadeo : http://minu.me/-jbfvia



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