Re: [FRnOG] [BIZ] Recherche fibre noire ou lambda 10G France-IX <=> Equinix PA4

2021-05-18 Par sujet Frederic Billy
Bonjour Gabriel, 

En effet comme le mentionne David nous pouvons vous aider et Sipartech ne fait 
pas que de la fibre noire.

C'est son produit historique mais notre portefeuille s'est beaucoup développé 
depuis (FON, EPL, Wave, IP, Hosting, ...) sur le territoire national français 
et européen.

Au plaisir d'échanger et de refaire le point ensemble. 

Cdt.

Frédéric BILLY
Sales Manager 



Le 18/05/2021 13:02, « frnog-requ...@frnog.org au nom de Gabriel Barazer via 
frnog »  a écrit :

Ah je ne savais pas que Sipartech faisait autre chose que de la fibre 
noire, bon à savoir !

Merci David pour l'info. Pour le remote peering sur France IX ce n'est 
vraiment pas clair et les offres des fournisseurs ne sont pas plus claires : 
est ce qu'on a un peering direct avec France IX ou est ce qu'on peer avec le 
fournisseur qui lui fournit les routes vers France IX ? Dans les deux cas, qui 
s'occupe du X connect entre France IX et le fournisseur, en théorie cela doit 
être inclus dans la prestation ? Je préfère pour ma part très largement la 
première méthode (sinon autant prendre un transit), mais je n'ai pas trouvé 
d'explication claire sur le service proposé ni le prix à ce sujet.

J'accepte bien volontiers les messages privés des différents fournisseurs 
s'ils ont plus d'infos (et des tarifs!) à ce sujet.

Gabriel

-Original Message-
From: David Ponzone  
Sent: mardi 18 mai 2021 12:47
To: Gabriel Barazer 
Cc: frnog-...@frnog.org
Subject: Re: [FRnOG] [BIZ] Recherche fibre noire ou lambda 10G France-IX 
<=> Equinix PA4

Sipartech par exemple, 225€/mois pour un lambda 10G passif.
Evidemment, faudra ajouter les X-co de chaque côté, donc environ 200€ de 
plus.

Mais y a d’autres fournisseurs capables de faire ça:
https://www.franceix.net/fr/members-resellers/remote-connection/

> Le 18 mai 2021 à 12:33, Gabriel Barazer via frnog  a 
écrit :
> 
> Bonjour à tous,
> 
> Suite à un projet d'upgrade 1G=>10G, nous recherchons un fournisseur soit 
de fibre noire soit une lambda 10G entre un des PoP de France-IX (cross connect 
inclus) et idéalement Equinix PA4 (Equinix PA2 possible mais moins pratique 
pour nous). Quelle serait la solution la plus pratique ou au meilleur prix ?
> 
> Concernant la fibre noire, nous pouvons éclairer jusqu'à 40Km sans 
problème, mais est ce que vous savez si France-IX est en mesure de le faire 
aussi ?
> 
> Autre proposition valable sinon , mais a mon avis plus couteuse (hors 
prix du routeur qu'on a déjà), disposer de 2U et 150W dans un PoP France-IX + 
fibre noire vers Equinix PA2 ou PA4.
> 
> Merci pour vos avis et réponses !
> 
> Gabriel
> 
> 
> ---
> 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] [BIZ] fournisseur Raritan

2021-04-09 Par sujet Frederic Hermann
Salut à tous, 

Puisque c'est la journée des [BIZ], je cherche un fournisseur Raritan (PDU), de 
préférence dans la région lyonnaise. 
C'est pas pour une très grosse commande mais si le courant passe bien, une 
relation pourrait s'établir dans la durée ! 

Bonne fin de semaine, 


FH 



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


[FRnOG] [BIZ] Recommandation de prestataires pour recyclage ou destruction de baies de disques/serveurs

2021-03-31 Par sujet Hardouin, Frederic
Bonjour !

 

Auriez-vous des contacts a recommander de prestataires qui interviennent
dans les DC pour recycler ou detruire des baies de disques/serveurs ?

Besoin de certificats officiels une fois le mauvais moment passe. Environ
800kg de materiel a recycler du cote d'Amsterdam.

A priori, pas de  possible ou recherche de broker.

 

Merci d'avance,

 

Frederic Hardouin


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


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

2021-03-19 Par sujet Frederic Robert

On 3/19/21 8:28 PM, Philippe ASTIER via frnog wrote:

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

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


Bonsoir,

Encore un coup de Johnny le rockeur :(

Bonne soirée,


--
Frédéric ROBERT


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


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

2021-02-16 Par sujet Frederic GROSJEAN
Bonjour,

>> Quelqu'un sait si il y a un outils opensource style une interface web, on
>> indique l'ip a surveiller, cela lance un ping permanent (ou qui ce
>> renouvelle toutes les x minutes sans periode de blanc)  et ou l'on peut
>> retrouver dans l'interface un mini compte rendu  ?

smokeping
https://oss.oetiker.ch/smokeping/

 Frédéric


De : frnog-requ...@frnog.org  de la part de David 
Ponzone 
Envoyé : mardi 16 février 2021 11:06
À : DUVERGIER Claude 
Cc : Lucas Viallon ; Frnog misc 
Objet : Re: [FRnOG] [MISC] Outils pour surveillance ping

Statping semble plus orienté HTTP/HTTPS, mais on peut aussi faire de l’ICMP.
A tester je pense.

> Le 16 févr. 2021 à 10:21, DUVERGIER Claude  a 
> écrit :
>
>
> Le 16/02/2021 à 09:29, Lucas Viallon a écrit :
>> Quelqu'un sait si il y a un outils opensource style une interface web, on
>> indique l'ip a surveiller, cela lance un ping permanent (ou qui ce
>> renouvelle toutes les x minutes sans periode de blanc)  et ou l'on peut
>> retrouver dans l'interface un mini compte rendu  ?
>
> Hello,
>
> En écosystème Prometheus (donc facilement utilisable sur une interface
> Grafana) il existe le Blackbox exporter
> (https://github.com/prometheus/blackbox_exporter) mais aussi d'autres
> exporter faisant exclusivement du ping :
>
> https://github.com/czerwonk/ping_exporter (Go)
>
> https://github.com/frankiexyz/ping-exporter (Python 2 + fping)
>
> Mais en cherchant d'autres exporter je suis tombé sur Statping
> https://github.com/statping/statping qui intègre sonde et interface et
> pourrait répondre directement au besoin.
>
> Fin de ma modeste contribution
>
> --
> DUVERGIER Claude
>
>
> ---
> 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: [BIZ] Re: [FRnOG] [MISC] Présentation Orchestration (NSO)

2021-02-12 Par sujet Hardouin, Frederic
Bonjour,

Peux-tu nous precise si la presentation en ligne sera en francais (slides + 
speech) ?
Merci,

Frederic


-Original Message-
From: frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] On Behalf Of 
Adrien Rivas
Sent: 12 February 2021 15:39
To: Remi Desgrange 
Cc: Clément THERY ; frnog-...@frnog.org
Subject: Re: [BIZ] Re: [FRnOG] [MISC] Présentation Orchestration (NSO)

CAUTION:  External email. Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

Oui, le trafic Nord / Sud correspond aux flux entrants / sortants, Est / 
Ouest aux déplacements latéraux dans le réseau.

Il me semble que c'est une notion assez récente, (et si je ne me trompe
pas) qui vient du design zéro trust (je laisse les colistiers corriger si 
besoin).

Le ven. 12 févr. 2021 à 11:45, Remi Desgrange 
 a écrit :

> Comme c'est vendredi je passe en MISC.
>
> Veuillez pardonner mon ignorance mais API nord et sud c'est quoi ? Y'a
> aussi Est et Ouest ?
>
> On Fri, Feb 12, 2021 at 9:43 AM Clément THERY
> 
> wrote:
>
> > Bonjour à tous,
> >
> > Comme c'est vendredi, je me permets de vous envoyer ce mail rapide.
> > L'idée, n'est pas de lancer un grand débat, mais plutôt d'inviter
> > ceux
> qui
> > le désire à une présentation en ligne. (La date reste à définir,
> > mais ce sera courant Mars)
> >
> > Aujourd'hui, de nombreux outils existent pour automatiser la
> > livraison de services (L2VPN, L3VPN, ...) sur les réseaux
> > opérateurs. Avec plus ou
> moins
> > d'efficacité, beaucoup sont capables de créer un service : ajouter
> > toutes les commandes nécessaires à partir d'une configuration
> > vierge. Moins sont capables de le mettre à jour ou encore de le
> > supprimer. Très peu sont capables de le réparer : retour arrière ou
> > remise en conformité des configurations. Combien sont capables de faire 
> > tout ça à la fois ?
> >
> > Nous vous proposons d'assister à une présentation de la solution
> > Cisco
> NSO
> > (Network Services Orchestrator). NSO est une plateforme de
> > développement agnostique au constructeur disposant de nombreuses API
> > Nord (REST,
> > NETCONF...) et Sud (RESTCONF, NETCONF, SSH...). Nous verrons qu'il
> > est capable de créer, mettre à jour, supprimer et réparer un service
> > ; mais qu'il est aussi capable de gérer des équipements de plusieurs
> > domaines
> (IP,
> > Optique) et de plus de 100 OS différents !
> >
> > Si assister à cette présentation en ligne vous intéresse, faites-moi
> > un mail avec vos coordonnées.
> >
> > Bonne journée
> >
> > Clément THERY
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
>
> --
> Cordialement, Rémi Desgrange
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


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


[FRnOG] [MISC] Suppression de compte XING au titre de la RGPD ?

2020-12-11 Par sujet Frederic Dumas



Bonjour,

quelqu'un saurait-il comment demander à XING la suppression de toutes 
mes données personnelles (et donc y compris mon compte), au titre de la 
RGPD ?


Le réseau social offre évidement la possibilité de demander la 
"suppression" d'un compte, par son utilisateur. Mais le bouton est si 
facilement accessible, et les gens du marketing "digital" si matois, que 
je me demande si ce bouton ne sert pas simplement à supprimer l'accès au 
compte (il disparait du front-end web), tandis que les données elles 
sont silencieusement conservées par XING.


Interrogé par écrit à propos des modalités de suppression au titre de la 
RGDP, le support Xing n'a pu répondre autrement que par un mail 
pré-formaté, rappelant l'existence du bouton en question, point barre.


Merci pour vos conseils.

--
Frederic Dumas
f.du...@ellis.siteparc.fr


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


Re: [FRnOG] [TECH] TNTSat - geolocalisation IP et sondes Atlas (titre un peu putaclic, c'est 'dredi)

2020-12-04 Par sujet Frederic Dumas




Le 04/12/2020 à 16:02, Hugues Voiturier a écrit :
Par Scaleway, pas Free, deux réseaux différents. Et si, il a été 
flag comme un range Néerlandais, puisque c’est le cas.



stat.ripe.net le signale lui comme français.

https://stat.ripe.net/widget/rir-geo#w.resource=51.158.0.0%2F15

Comment voit-on que 51.158.0.0/15 annoncé par AS12876 est un range 
hollandais ?




Ce préfixe est celui de Scaleway à Amsterdam



Tu veux dire que la filiale de Free est de droit néerlandais? C'est une 
histoire de double sandwich irlandais au gouda?



--
Frederic Dumas
f.du...@ellis.siteparc.fr


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


[FRnOG] [TECH] TNTSat - geolocalisation IP et sondes Atlas (titre un peu putaclic, c'est 'dredi)

2020-12-04 Par sujet Frederic Dumas



Un sujet plus léger pour vendredi.


Le site TNTsat interdit de commander une nouvelle carte depuis une IP 
étrangère (le genre de truc que la commission européenne dénonce, mais bon).


Pour déjouer cette limite j'imaginais qu'une DediBox dans le range 
51.158.128.0/17 utilisée en proxy ferait l'affaire.


Pour le moment, tous mes efforts sont infructueux: invariablement, 
"CANAL+ n'est pas disponible dans votre pays".



 - tunnel SOCKSv5 depuis ma machine locale jusqu'à la Dedibox
   + WebRTC IP leak désactivé dans Firefox

   "CANAL+ n'est pas disponible dans votre pays"


 - l'IPv6 de la DediBox est localisée en Hollande (?!?)
   Stack IPv6 désactivée.

   "CANAL+ n'est pas disponible dans votre pays"


 - consultation du site TNTSat en ligne de commandes, avec links,
   depuis la DediBox

   "CANAL+ n'est pas disponible dans votre pays"


J'en viens à me demander si le range 51.158.0.0/15, annoncé par Free, 
n'aurait pas été flagé dans le temps comme un range non français ?


https://stat.ripe.net/51.158.0.0%2F15#tabId=routing

Malheureusement, son historique par les sondes Atlas ne remonte pas 
au-delà de 2018.



J'imagine que si le webmestre du site canal lit la liste, il accrochera 
mon mail à son tableau de chasse. :-)



--
Frederic Dumas
f.du...@ellis.siteparc.fr


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


Re: [FRnOG] [TECH] Codecs VoIP sur OVH

2020-12-04 Par sujet Frederic Dumas



Hello,


Le 04/12/2020 à 11:58, David Ponzone a écrit :

Personne a envie de se taper du transcoding à la place des autres

Donc c’est la patate chaude: non non j’en veux pas de ton G729,
envoie-moi du bon 711 qui prend 0% de CPU à relayer.


Intéressant d'apprendre que l'opérateur est incité à favoriser G711 pour 
tous les appels terminés par un opérateur tiers, pour s'éviter de les 
transcoder.



Le 04/12/2020 à 11:49, Oliver varenne a écrit :

Je ne vois pas le probleme...


Le problème venait de la réponse formulée par le support technique: elle 
donnait à croire que la négociation du codec se faisait de bout en bout, 
pour chaque communication, où que soit terminé l'appel.



Le 04/12/2020 à 14:13, Sébastien Lesimple a écrit :
J'ai lu quelque part dans leurs docs que le G722 n'était supporté 
qu'entre deux lignes OVH pas vers l'extérieur qui doit est soit en

SS7, soit en G711.


C'est peut-être ce qu'a voulu dire le support OVH: si l'appel est 
terminé par un opérateur tiers, OVH négocie G711, si l'appel est terminé 
chez OVH, G722 est négocié. Dis comme ça c'est plus clair.



Merci à tous pour vos réponses.

--
Frederic Dumas
f.du...@ellis.siteparc.fr


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


Re: [FRnOG] [BIZ] Recherche de prestataires intégrateurs SOPHOS, UBIQUITI et MIKROTIK

2020-11-10 Par sujet Frederic Mailhol
Bonjour CEM, tu as SYS1 à Bordeaux expert sur ces produits...
Tu peux appeler de ma part!

Frédéric Mailhol

> Le 10 nov. 2020 à 16:00, Matthieu Courtois  a 
> écrit :
> 
> Salut Cem,
> 
> Pour nos Sophos nous passons par Protego http://www.protego.net/
> 
> Matthieu.
> 
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de 
> cem.car...@free.fr
> Envoyé : mardi 10 novembre 2020 15:11
> À : frnog-...@frnog.org
> Objet : [FRnOG] [BIZ] Recherche de prestataires intégrateurs SOPHOS, UBIQUITI 
> et MIKROTIK
> 
> Bonjour à tous sur la liste, 
> 
> Je recherche pour les besoins de la DSI de la ville des prestataires qui 
> maitrisent les équipements UTM de la marque SOPHOS (gamme SG XXX). 
> Les prestations demandées sont migration depuis d'autres UTM, paramétrages et 
> transfert de compétences auprès de l'équipe interne. 
> 
> D'autre part, j'ai besoin de soulager notre charge de travail en 
> sous-traitant une partie des déploiements UBIQUITI (liaisons inter-batiments 
> et WiFi). 
> Ces prestations auront également pour but de déployer, paramétrer et 
> transférer des compétences en interne. 
> Accessoirement, si les prestataires n'ont pas la migraine en voyant des 
> produits MIKROTIK c'est un plus !!! 
> 
> Blague à part, on a beaucoup de chantiers historiques pour lesquels nous ne 
> sommes pas assez nombreux et cela traine depuis trop longtemps... 
> 
> Si le mandat administratif payé dans les délais ne vous fait pas peur et que 
> vous êtes pas trop loin de Meaux (c'est relatif), on peut travailler ensemble 
> (bon après y'a toujours les 3 devis hein ) ! 
> 
> Bonne après-midi à tous. 
> 
> 
> Cem 
> DSI de la ville de Meaux / Agglo du Pays de Meaux 
> 
> 
> ---
> 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] Gmail quête d'explication

2020-06-09 Par sujet Frederic Robert

On 6/9/20 3:29 PM, Jarod G. wrote:

Malheureusement c'est ce qui arrive quand on a quelques entreprises qui
monopolisent le domaine du mail, ça va te bloquer sévère sous prétexte
que t'es potentiellement dangereux...
Sur mes deux domaines perso j'ai pas eu de problème, mais sur d'autres
ça a été une catastrophe pour que ça communique à nouveau...
Jamais eu de réponse de la part de Google, c'était repartit comme si de
rien n'était, pour Microsoft par contre :

"Pour des raisons de sécurité, nous ne sommes pas en mesure de vous
communiquer les différents éléments mettant en cause un domaine ou une
ip / un bloc d'adresses ip."

Jarod G.


Bonjour Jarod et à la liste,

Sauf erreur de ma part, j'ai l'impression que c'est fait exprès pour que 
les particuliers et entreprises hébergent leurs serveurs mails chez 
microsoft et google. C'est triste pour ceux qui s'auto hébergent


Très bonne fin de journée,

--
Frédéric ROBERT


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


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

2020-05-09 Par sujet Frederic Dhieux

Bonjour,

D'une part la proposition a 20 ans de retard (c'est pas le premier à 
chercher à gratter de la place dans le header pour étendre l'IPv4), mais 
les problèmes sont les mêmes que pour IPv6 hormis la double stack.


La réalité (et c'est expliqué environ 50 fois dans le thread du RIPE), 
c'est que tu dois adapter quand même les équipements concernés, que le 
bit en question peut être réécrit ou reset ou utilisé et dans ce cas tu 
perds l'extension, que pire encore sur une non prise en compte de ce 
bit, tu peux te retrouver avec une IP dupliquée qui peut poser des 
problèmes sur des ACL et que comme dit Radu, à un moment en end point tu 
as une IP qui est 32 bits sans rien d'autre et que voilà.


Si c'est pour taper dans les trucs non prévus, autant exploiter la 
classe E 240.0.0.0/4 réservée pour utilisation future (quel futur ?). A 
priori Windows le gère pas, mais ce serait surement plus simple de 
débloquer ça qu'utiliser un bit "magique".


La proposition n'a aucun fondement concret, aucune sous couche 
technique, aucun POC, aucune proposition solide.


Le mec utilise une méthode bien à la mode pour essayer de se faire élire 
en promettant des trucs magiques (sa proposition anti-spam est du même 
accabit), c'est du Trump like quoi. Sachant que le RIPE n'est pas 
l'organisme qui décide de tout ça en plus.


Je suis effrayé de voir qu'un tel ce non sens a réussi à générer autant 
de volume de discussions et je m'inquiète de voir des gens croire en ce 
marabout de l'an 2020. Entre Trump et les débilités qu'on voit 
concernant Coronavirus et la 5G régulièrement, j'espère qu'au moins la 
communauté des membres du RIPE a globalement plus de discernement que ça.


Voilà que même au RIPE on se tape de promesses de politiciens...

Fred

Le 09/05/2020 à 16:51, Bruno LEAL DE SOUSA a écrit :

Bonjour Johann et bonjour à tous,

Merci pour ces explications mais j'ai juste répondu un peu vite et pas dans
le bon sens.
En effet lorsqu'on regarde en détail sa proposition et surtout ses méthodes
cela fait peur et l'application semble impossible voir catastrophique.

Après je pense que la réflexion qu'il a apporté a juste 10 ou 20 ans de
retard. Il aurait fallu y songer avant de propulseur IPv6.
Je pense que le passage de IPv4 à IPv6 est juste trop brutal et mal
organisé aujourd'hui. Beaucoup vont se casser les dents en termes de
sécurité dans les années à venir à cause de ce changement trop brutal.
Un changement ne peut être réussi que quand il est adapté, pas trop brusque
et accompagné. Je trouve donc dommage que ce genre de proposition ou de
réflexion apparaissent bien trop tard.

Maintenant il est certain que ces propositions manquent de sens et de
possibilité de réalisation. Des belles promesses de politiciens encore...

Espérons qu'il ne réussisse pas à gagner le combat des élections.

Bonne journée à tous.

Bruno LEAL DE SOUSA
06.01.23.45.96

Le sam. 9 mai 2020 à 16:38, Johann  a écrit :


Bonjour Bruno,

Pour répondre un peu plus sur la partie technique, car j'imagine que
beaucoup de gens ici n'ont pas pris le temps de lire l'ensemble du thread.
Ou n'ont tout simplement pas le background technique suffisant (ce n'est
pas une insulte) pour juger en profondeur de celle-ci.

TECHNIQUEMENT PARLANT :
Son idée, c'est de dire qu'on va créé une extension d'IPv4, qui
utiliserait la même structure de paquet et qui serait en plus
rétrocompatible.
Cela permettrait de doubler le nombre d'IPv4 disponible et donc d'éviter
l'apocalypse. Ça c'est la promesse papier électorale.

Humainement parlant, on aurait les IPv4 classiques
[0-255].[0-255].[0-255].[0-255] et les IPv4+ [0-65535].[0-65535].
Côté équipement, il propose d'utilisé le bit "réservé" dans la partie FLAG
du header IPv4 pour indiqué si c'est de l'IPv4+.
Après tout, pourquoi pas, même si on sait d'expérience qu'un bit ou une
plage d'IP réservée est souvent difficile à utilisé dans le futur.

Mais la où ça commence à sentir mauvais, c'est quand on lit le détail de
la technique et du déploiement.
Celui-ci propose d'utiliser les autres bits de la partie FLAG, le bit DF
(don't fragment) et MF (more fragment), qui eux sont utilisés dans nos
réseaux  pour la gestion de la fragmentation.
C'est à dire qu'à partir de ce moment dans la lecture, on casse tout ce
qui est mécanisme de fragmentation de paquet sur les réseaux IPv4 "legacy".
Ces bits DF et MF seraient utilisés pour savoir si l'adresse source ou de
destination est au format IPv4+. Pour la rétrocompatibilité avec IPv4.

Où clairement j'ai halluciné, c'est sur la justification de pourquoi ces
bits :
- Le champs ToS peut être modifié sur le chemin
- Le champs IP-ID peut être modifié sur le chemin
- Les champs DF et MF ne peuvent pas modifiés sur le chemin (!?!!!??)

Ce monsieur justifie que les bits de fragmentation sont "optional by
design" et que si on connait la MTU, on en a en faite pas besoin.
Ce qui est absolument faux, c'est d'ailleurs tout le principe de la chose.
On ne peut pas connaitre la MTU sans MTU 

Re: [FRnOG] [TECH] Changement Cisco ?

2020-03-25 Par sujet Frederic Dhieux
Bonjour,

Pour du routeur pur, je suis passé de 7600/6500 à ASR900X il y a 6 ans
et j'en suis super content. C'est robuste, l'OS change mais quelque part
c'est assez familier avec des améliorations donc gagnant-gagnant à ce
niveau là et c'est rock solid chez nous.

Seul bémol pour moi comparativement à avant, avoir eu à payer une
licence pour les VRF (et encore on est toujours limités à 8 avec la
licence qu'on a choisi). Pour le reste c'est top, rien à dire en 6 ans.

Je ne vais pas encourager Cisco et leur façon de traiter le marché
parfois, mais faut reconnaitre que certains produits sont juste
efficaces et stables et pour moi l'ASR9K en fait partie.

Pour le contexte, chez nous qui ne sommes pas un opérateur, ça sert de
coeur avec les transits et peerings, une poignée de VRF, le MPLS bien
sûr et quelques tunnels L2 dessus et les edges en BGP (en mode client
BGP pour chaque BU) et des ACL sur les ports d'entrée internet. Et bien
sûr dual stack IPv4/IPv6.

Le 25/03/2020 à 14:05, Lucas Viallon a écrit :
> Merci pour ta réponse,
>
> Dans mon cas, j'ai vraiment tendance a rester cisco que je connais et dont
> le taux de satisfaction chez nous et de l'ordre de 99%,
> j'ai déjà essayé d'aller vers du juniper, du mikrotik ou du libre et
> sincèrement je m'en suis toujours mordu les doigts.
>
> Au niveau budget, je suis justement en train de le définir, on s'adaptera
> mais on préférera payer un peu plus chère pour du cisco
> que perdre du temps a retester d'autres plateformes
>
> au vu des conseils, je pense commander un ASR en 9900 pour tester, on verra
> bien
>
> Le mer. 25 mars 2020 à 12:43, Jérôme Nicolle  a écrit :
>
>> Salut Lucas,
>>
>> Le 25/03/2020 à 11:39, Lucas Viallon a écrit :
>>> Il y a quelqu'un qui a deja fait ce genre de changement ? vous etes
>> partie
>>> sur sur quelle gamme ?
>> Juniper MX / ACX / QFX le plus souvent, Arista ou Cumulus par ailleurs.
>>
>> Su tu restes en Cisco, de toute façon tu vas changer d'OS en passant à
>> IOS-XR donc quitte à refaire tout ton design autant en profiter pour
>> regarder à coté. En fonction de ce que tu veux en faire, il peut y avoir
>> un réel intérêt à changer de fabricant.
>>
>> N'oublies pas d'évaluer les NCS5500 aussi, ils en ont gros sous le pied.
>>
>> @+
>>
>> --
>> 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/


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


Re: [FRnOG] [TECH] Peering Free<->Verizon saturé ?

2020-03-23 Par sujet Frederic Dhieux
Il doit y avoir une solution de Visio chez eux. Auquel cas Free est en
droit bien entendu de demander plein d'argent à Verizon pour oser
utiliser ses tuyaux abonnés pour de la vidéo, surtout que l'abonné
envoie 1 vidéo et en reçoit plusieurs :o

Pardon on n'est pas encore vendredi.


Le 23/03/2020 à 13:20, Sébastien Lesimple a écrit :
> Comment qui disaient à la TV?
> "T'as Free, t'as tout compris"... Ou pas.
>
> Bon faut reconnaître que c'est pas prévu pour faire du pro en
> Teletravail et que l'AS702 de Verizon aujourd'hui porte plus grands
> choses de généraliste.
> Dailleurs VZ en France de nos jours, c'est Waterloo morne plaine.
>
> Le 23/03/2020 à 13:14, David Ponzone a écrit :
>> La morale c’est que le GP qui a choisi Free à la maison pour le prix doit 
>> maintenant assumer son choix.
>>
>> Et le FAI qui a choisi Cogent, idem :)
>>
>> Oui je sais, on est pas vendredi.
>>
>>> Le 23 mars 2020 à 12:50, Hervé BRY  a écrit :
>>>
>>> Bonjour,
>>>
>>> J'ai constaté une saturation entre Cogent (principal transitaire de Free)
>>> et Telia aux heures de pointe.
>>> Ca semble saturer aussi entre SFR et Telia.
>>>
>>> Pour ma part j'ai heureusement pu router ces deux destinations par un autre
>>> transitaire que Telia.
>>>
>>> Hervé BRY
>>> Administrateur Système
>>> Geneanet (http://www.geneanet.org)
>>>
>>>
>>> Le lun. 23 mars 2020 à 12:46, Ronan De Kermadec <
>>> rdekerma...@transnumeric.com> a écrit :
>>>
 Bonjour à tous,

 Avec l’adoption massive du télétravail la semaine dernière nous constatons
 de fortes lenteurs/pertes de paquets (environ 25%) pour tous nos
 utilisateurs connectés chez Free.

 Nous avons ouvert un ticket chez Verizon (notre ISP) qui a escaladé le
 ticket en interne. Verizon indique que le peering entre Free et Verizon
 (entre 194.149.166.34 et 146.188.112.253) est complètement saturé entre 9h
 et 12h puis entre 14h et 17h30. Free a été sollicité pour éventuellement
 planifier un upgrade mais Verizon n’a eu aucun retour de leur part pour le
 moment semble-t-il !

 J’ai tenté d’ouvrir un ticket chez Free à ce sujet afin de pouvoir
 échanger avec les équipes backbone malheureusement sans grand succès.

 Si quelqu’un de chez Free passe par là ou si vous connaissez quelqu’un qui
 pourrait faire avancer les choses, merci de prendre contact avec moi afin
 que je puisse vous donner plus de détails.

 Je ne pense pas que nous soyons les seuls à constater ce problème,
 y’a-t-il d’autre personnes qui subissent ces lenteurs ?

 Merci d’avance pour votre aide précieuse !

 Ronan


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

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


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


Re: [FRnOG] [ALERT] Intervention Equinix, changement de procédure d'accès à partir de demain

2020-03-22 Par sujet Frederic Dhieux
Hello,

C'est une période exceptionnelle et une situation exceptionnelle, il
faut faire avec. Les gens qui n'ont pas anticipé vont morfler, il faudra
faire au mieux avec les moyens du bord (les techs du DC), faire livrer
le matos et donner les consignes.

C'est pas comme si on ne l'avait pas vu arriver depuis des semaines
cette situation, sans compter la période des grèves massives où déjà on
aurait du réfléchir un peu plus à l'adaptation des outils de
télétravail. Critiquer un gouvernement qui a mal anticiper c'est facile
(et je le fais aussi), mais au final ils ne sont pas les seuls à avoir
mal géré la situation depuis 1 mois.

Bravo aux DC de maintenir un service pour le client. Il est courageux et
difficile d'interdire l'accès client, mais c'est une mesure raisonnable
pour limiter les risques dans ces lieux sensibles, on a besoin d'eux !

 Fred

Le 22/03/2020 à 17:34, Johann a écrit :
> Hello Arnaud,
>
> Entièrement d'accord avec toi. Mais il y a une différence entre ceux qui
> viennent faire des selfies devant une baie, et ceux qui travail pour faire
> cette continuité et absorbé l'augmentation de trafic des clients.
> Ceux-ci devraient pouvoir continuer à intervenir dans des conditions
> strict. Et ne me demande pas de laisser faire des manipulations complexes à
> Equinix, on a déjà vu les dégâts que ça peut occasionner...
> Clairement, si aucun accès n'est possible, on va avoir des problèmes sur le
> moyen terme.
>
> Johann
>
>
> Le dim. 22 mars 2020 à 17:14, Arnaud  a
> écrit :
>
>> C’est une très bonne chose !
>> Vous ne vous rendez pas compte de l’importance cruciale de ces sites
>> sensible en ce moment.
>> Les selphies devant les baies attendront (j’en ai vu sur twitter, et à
>> Paris !), en attendant, on doit tout faire pour protéger les techniciens
>> des DC qui se démènent en ce moment à faire toutes les interventions client
>> et maintenir la continuité technique des sites.
>> Gloire à eux !
>> Arnaud
>>
>>
>>
>>> Le 22 mars 2020 à 14:15, David Ponzone  a
>> écrit :
>>> Ils sont oufs.
>>> Si encore, ils étaient passés par la case « Appointment-only » comme ils
>> ont annoncé qu’ils feraient si nécessaire, on aurait pu sentir le truc
>> arrivé.
>>> Y a plus qu’à croiser les doigts.
>>
>> ---
>> 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] Profitons bien de l'épidémie pour violer un peu la neutralité

2020-03-16 Par sujet Frederic Dhieux
Bonjour,

Oui je pense que les tuyaux posent moins de soucis que les services pas
taillés pour le nombre de connexions. Cette période va être
intéressante, on va sentir toutes les économies faites en mettant les
curseurs au plus bas dans les entreprises et organismes.

Genre j'ai vu des entreprises demander à des collaborateurs de ne pas
télétravailler car le VPN n'était pas taillé pour supporter tout le
monde :) C'est un peu dommage, surtout quand on a été préparé par les
grêves quelques semaines/mois avant =)

Le 16/03/2020 à 13:28, Alarig Le Lay a écrit :
> Le souci ne vient toujours pas de la taille des tuyaux. Ils ont résisté
> à la coupe du monde des 11 glandus derrière un ballon, ils résisterons à
> ça.
>
> On lun. 16 mars 12:50:06 2020, Nico G wrote:
>> Le core ça doit tenir sans problème. Certains lien edge peut être pas.
>> Le peering vers Netflix ou Google c’est du privé et c’est largement 
>> dimensionné. Le transit généraliste vers tel ou tel hébergeur c’est moins 
>> sur. D’autant plus qu’Orange n’a pas le peering dans le sang.
>>
>> Nicolas
>>
>>> Le 16 mars 2020 à 12:30, Richard Klein  a écrit :
>>>
>>> @David
>>> La question est de savoir si la saturation est sur le cœur et si les
>>> opérateurs et acteurs des télécoms seront tirer la leçon pour investir
>>> Et si payer une fibre un bras et se retrouver avec des ralentissements
>>> c'est les prochaines questions qui seront abordés par les clients...
>>>
 Le lun. 16 mars 2020 à 12:25, David Ponzone  a
 écrit :

 J’ai pas bien compris le rapport entre ma fibre et les sites web de
 support scolaire des écoles….

>> Le 16 mars 2020 à 12:06, Richard Klein  a écrit :
> Bonjour a tous depuis la maison pendant ma pause déjeuné.
> Je me fais l'avocat du diable...
> Question lorsque vous payez une fibre 500euros et lorsque vous payez 30
> euros en GP vos debits sont garantis pour la ligne GP ou Pro?
> :-)
>
> Richard
>
> Le lun. 16 mars 2020 à 11:44, GROS Jérôme  a écrit
 :
>> Pour l'école primaire chez moi :
>> https://beneylu.com/fr/beneylu-school-met-les-bouchees-doubles/
>> Bon là, même le message d'alerte ne fonctionne plus.
>>
>> On Mon, Mar 16, 2020 at 10:10:53AM +0100, David Ponzone wrote:
>>> Des sources de quoi ?
>>> Ben EcoleDirecte de mon fils: inutilisable à l’heure actuelle.
>>> VieScolaire de ma fille: inutilisable
>>> Kwyk dont se sert la prof de maths de mon fils: inutilisable toute à
>> l’heure, ça a l’air d’aller un peu mieux là.
>>> Paris Classe Numérique marchait pas ce matin (accès prof), mais ça
 semble
>> s’améliorer.
>>> Y a donc pas grand chose qui support les accès massifs et comme rien
 n’a
>> été fait pour les étaler dans le temps...
 Le 16 mars 2020 à 10:03, Michel Guillou  a écrit :

 Le Mon, 16 Mar 2020 09:52:07 +0100, vous écrivîtes :

> S’ils font ça, ils sont morts.
> Même certains profs comptent sur Youtube pour fournir le contenu que
>> le Ministère n’a pas.
> Je parle même pas des serveurs type EcoleDirect et autres, qui ont
>> gentiment explosé ce matin.
 Tu as des sources là-dessus ? Ça m'intéresse...

 Merci.

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


[FRnOG] [BIZ] Fournisseur stock Ruckus

2020-02-26 Par sujet Frederic Hermann
Bonjour la liste, 

Je cherche un fournisseur Ruckus en France (c'est pas pour moi c'est pour un 
ami...). 
A priori c'est pour un ensemble de petits projets (environ 10-15 AP 
indoor/outdoor a chaque fois), et il semble que ça soit compliqué d'avoir des 
bons prix, alors si vous avez un bon contact chez un fournisseur / grossiste 
... 

Merci ! 






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


Re: [FRnOG] [TECH] Pb envoi mail vers smtp-in.orange.fr

2020-02-13 Par sujet Frederic Robert

On 2/13/20 3:17 PM, Frederic Hermann wrote:

Est-ce qu'on est juste blacklisté chez eux (ça peut arriver), ou est-ce que 
c'est plus général ?


Bonjour,

Idem depuis Hetzner (Allemagne)

Bonne journée,

--
Frédéric ROBERT


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


[FRnOG] [TECH] Pb envoi mail vers smtp-in.orange.fr

2020-02-13 Par sujet Frederic Hermann
Bonjour, 

Nous rencontrons actuellement des problèmes pour délivrer nos messages 
sortants vers les adresses en orange.fr ou wanadoo.fr avec l'erreur suivante : 

(host smtp-in.orange.fr[193.252.22.65] refused to talk to me: 421 mwinf5c10 ME 
Service refuse. Veuillez essayer plus tard. Service refused, please try later. 
OFR_108; [108]) 
ou 
(delivery temporarily suspended: host smtp-in.orange.fr[193.252.22.65] refused 
to talk to me: 421 mwinf5c10 ME Service refuse. Veuillez essayer plus tard. 
Service refused, please try later. OFR_108; [108]) 

Est-ce qu'on est juste blacklisté chez eux (ça peut arriver), ou est-ce que 
c'est plus général ? 

Pour info, le smtp sortant est heb-nep-25-smtp.neptune.fr 

Merci de vos retour. 



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


Re: Re: [FRnOG] [MISC] pb sur bornes UAP AC: perte d'accès internet sans perte du LAN

2020-02-12 Par sujet Frederic Trate ftrate via frnog
I will be out of office from February,10th through February, 17th with no 
access to emails.
Regards,
Frederic.

On 10 Feb 2020, at 18:17, Daniel via frnog  wrote:


Le 10/02/2020 à 18:13, Philippe ASTIER a écrit :
Euh, pas LAN vers WAN, mais vers WLAN, c’est pas pareil.

Extrait de l'UI

Filtrage Multicast et Broadcast <> Bloquer les données multicast et broadcast 
de LAN vers WAN

Donc, si je vous suis, les bornes filtreraient les réponses ARP (en broadcast) 
uniquement de la gateway, mais pas du reste du LAN ? Ca parait très gros comme 
bug.
La gateway, par définition, fait bien partie du LAN…

J’ai du mal à être convaincu que ce soit le souci. En plus, j’ai utilisé cette 
option sur plusieurs réseaux Unifi, plusieurs générations de firmware, sans 
jamais souffrir de ce symptôme.



Le 10 févr. 2020 à 18:06, Daniel via frnog mailto:frnog@frnog.org>> a écrit :


Le 10/02/2020 à 18:00, Philippe ASTIER a écrit :
Ce qui me dérange dans la description c’est qu’il nous a dit que seule la 
gateway ne répondait pas. Si le trafic marche sur le LAN, c’est qu’ARP marche 
sur le LAN aussi.
L'option bloque de LAN vers WAN, pas LAN<>LAN

J’en reviens à ce que je disais, regarder si le Zyxel n’est pas le coupable, 
puisque c’est lui qui ne répond plus.

Wireshark is our friend.


Le 10 févr. 2020 à 17:53, Michel Py mailto:mic...@arneill-py.sacramento.ca.us>> a écrit :

Hervé BRY a écrit :
Ca me rappelle très fort un problème que j'ai eu en activant sans y prendre 
garde l'option
"Enable Multicast and Broadcast Filtering" (sur le contrôleur Unifi, dans les 
paramètres
du réseau-wifi en question).> Le filtrage était un peu trop efficace et 
bloquait des requêtes
ARP indispensables, comme celle pour trouver la MAC de la gateway par exemple...
Je plussoie, çà sent l'ARP filtré à plein nez.


--
Daniel Huhardeaux
+33.368460...@tootai.net sip:8...@sip.tootai.net
+41.445532...@swiss-itech.ch   tootaiNET


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

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


Re: Re: Re: [FRnOG] [TECH] Client VPN IKEv2 Free (Autre que le client windows)

2020-02-12 Par sujet Frederic Trate ftrate via frnog
I will be out of office from February,10th through February, 17th with no 
access to emails.
Regards,
Frederic.

On 12 Feb 2020, at 17:24, Frederic Trate ftrate via frnog  
wrote:

I will be out of office from February,10th through February, 17th with no 
access to emails.
Regards,
Frederic.

On 11 Feb 2020, at 22:02, Guillaume Tournat via frnog  wrote:

FortiClient de Fortinet : le module VPN (ipsec et ssl) est gratuit.

https://www.forticlient.com/downloads


Le 11 févr. 2020 à 21:15, Alexandre VALENTIN  a écrit :

Bonsoir la liste,

Je chercher un clients VPN windows du même style que shrewsoft mais qui me
permet de faire de l'IKEv2.
Vous avez ça en stocke?

Ne me dite pas le client Windows svp!

Merci et bonne soirée

Alexandre VALENTIN
@ : alexandre...@gmail.com
Tel : 07.68.63.34.74

---
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: Re: [FRnOG] [MISC] pb sur bornes UAP AC: perte d'accès internet sans perte du LAN

2020-02-12 Par sujet Frederic Trate ftrate via frnog
I will be out of office from February,10th through February, 17th with no 
access to emails.
Regards,
Frederic.

On 10 Feb 2020, at 18:06, Daniel via frnog  wrote:


Le 10/02/2020 à 18:00, Philippe ASTIER a écrit :
Ce qui me dérange dans la description c’est qu’il nous a dit que seule la 
gateway ne répondait pas. Si le trafic marche sur le LAN, c’est qu’ARP marche 
sur le LAN aussi.
L'option bloque de LAN vers WAN, pas LAN<>LAN

J’en reviens à ce que je disais, regarder si le Zyxel n’est pas le coupable, 
puisque c’est lui qui ne répond plus.

Wireshark is our friend.


Le 10 févr. 2020 à 17:53, Michel Py  a 
écrit :

Hervé BRY a écrit :
Ca me rappelle très fort un problème que j'ai eu en activant sans y prendre 
garde l'option
"Enable Multicast and Broadcast Filtering" (sur le contrôleur Unifi, dans les 
paramètres
du réseau-wifi en question).> Le filtrage était un peu trop efficace et 
bloquait des requêtes
ARP indispensables, comme celle pour trouver la MAC de la gateway par exemple...
Je plussoie, çà sent l'ARP filtré à plein nez.

Michel.


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

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

--
Daniel Huhardeaux
+33.368460...@tootai.net sip:8...@sip.tootai.net
+41.445532...@swiss-itech.ch   tootaiNET


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

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


Re: Re: [FRnOG] [MISC] Souci de stabilité avec sonde Atlas

2020-02-12 Par sujet Frederic Trate ftrate via frnog
I will be out of office from February,10th through February, 17th with no 
access to emails.
Regards,
Frederic.

On 12 Feb 2020, at 09:47, Alexandre GRIVEAUX via frnog  wrote:

Le 11/02/2020 à 22:52, Richard Baret a écrit :
J'ai essayé de monter les partitions de la clé, erreur de superblock
etc... Ca confirme bien que le FS se corrmpt à un certain moment.
Bon ben je vais continuer de la reset régulièrement. A moins qu'il
soit possible de la changer par une v4 mais j' ai des doutes.

Merci pour vos retours,

Richard

On 2/11/20 8:20 PM, Hugues Voiturier wrote:
Attention, les partitions sont chiffrées.


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

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


Re: Re: [FRnOG] [TECH] Client VPN IKEv2 Free (Autre que le client windows)

2020-02-12 Par sujet Frederic Trate ftrate via frnog
I will be out of office from February,10th through February, 17th with no 
access to emails.
Regards,
Frederic.

On 11 Feb 2020, at 22:02, Guillaume Tournat via frnog  wrote:

FortiClient de Fortinet : le module VPN (ipsec et ssl) est gratuit.

https://www.forticlient.com/downloads


Le 11 févr. 2020 à 21:15, Alexandre VALENTIN  a écrit :

Bonsoir la liste,

Je chercher un clients VPN windows du même style que shrewsoft mais qui me
permet de faire de l'IKEv2.
Vous avez ça en stocke?

Ne me dite pas le client Windows svp!

Merci et bonne soirée

Alexandre VALENTIN
@ : alexandre...@gmail.com
Tel : 07.68.63.34.74

---
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: Re: [FRnOG] [TECH] Client VPN IKEv2 Free (Autre que le client windows)

2020-02-12 Par sujet Frederic Trate ftrate via frnog
I will be out of office from February,10th through February, 17th with no 
access to emails.
Regards,
Frederic.

On 11 Feb 2020, at 22:02, Guillaume Tournat via frnog  wrote:

FortiClient de Fortinet : le module VPN (ipsec et ssl) est gratuit.

https://www.forticlient.com/downloads


Le 11 févr. 2020 à 21:15, Alexandre VALENTIN  a écrit :

Bonsoir la liste,

Je chercher un clients VPN windows du même style que shrewsoft mais qui me
permet de faire de l'IKEv2.
Vous avez ça en stocke?

Ne me dite pas le client Windows svp!

Merci et bonne soirée

Alexandre VALENTIN
@ : alexandre...@gmail.com
Tel : 07.68.63.34.74

---
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] recherche 4 VMs avec 4 opérateurs différents

2020-02-11 Par sujet Frederic macaigne
L'idée est bonne pour un besoin qui rentre à 100% dans ce que sais faire
une sonde atlas. Je ne connaissais pas: merci pour l'info.
J'ai des tests à faire un peu plus poussés que ce que la sonde atlas sait
faire et j'ai déjà ma solution de test.
Reste à trouver le ou les bons fournisseurs pour les VMs.

Mais encore une fois merci pour l'info sur les sondes atlas: ce sera
ré-utilisé...


Fred

On Tue, Feb 11, 2020 at 2:53 PM Julien Escario 
wrote:

> Le 11/02/2020 à 14:28, Frederic macaigne a écrit :
> > Salut a toutes et à tous,
>
> Salut,
>
> > pour des besoins de test, j'ai besoin de un ou plusieurs fournisseurs qui
> > seraient capable de me louer un ou plusieurs VMs depuis lesquelles je
> vais
> > initier un test (imaginez un trace route) sur un ou plusieurs opérateurs.
> >
> > Ce qu'il me faut ce sont des VMs avec un control de quel opérateur me
> > laisse sortir du DC et sans fail-over (ou alors sur le même opérateur).
> >
> > Une fois cela dit, le reste est flexible: un, 2, 3 ou 4 fournisseurs. 1,
> 2,
> > 3 ou 4 VMs. Les opérateurs par lesquels j'ai besoin de sortir sont: Colt,
> > Tata, Orange et Verizon.
>
> Et avec RIPE Atlas ? Tu dois pouvoir trouver des sondes chez chacun de
> ceux là sans trop de soucis.
>
> Julien
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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


[FRnOG] [BIZ] recherche 4 VMs avec 4 opérateurs différents

2020-02-11 Par sujet Frederic macaigne
Salut a toutes et à tous,

pour des besoins de test, j'ai besoin de un ou plusieurs fournisseurs qui
seraient capable de me louer un ou plusieurs VMs depuis lesquelles je vais
initier un test (imaginez un trace route) sur un ou plusieurs opérateurs.

Ce qu'il me faut ce sont des VMs avec un control de quel opérateur me
laisse sortir du DC et sans fail-over (ou alors sur le même opérateur).

Une fois cela dit, le reste est flexible: un, 2, 3 ou 4 fournisseurs. 1, 2,
3 ou 4 VMs. Les opérateurs par lesquels j'ai besoin de sortir sont: Colt,
Tata, Orange et Verizon.

Des idées?

Fred

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


Re: [FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?

2019-12-13 Par sujet Frederic Dumas



Merci Fabien, Philippe, Raphaël pour vos réponses.

Par le calcul, je n'arrive pas à retrouver vos conclusions.

Au moment des tests, j'avais un rtt de 174ms en moyenne et un jitter de 
10ms. J'étais cappé à 132Mbps (pas MBps, coquille). Et aucun paquet n'a 
été réémis; pas de pertes. Si le facteur qui a limité le débit, c'est 
comme vous le suggérez la fenêtre TCP et non pas un shapping du trafic 
par l'opérateur, la fenêtre aurait été à ce moment là de ~2,8Mio. Je 
lisais que sa taille peut théoriquement aller jusqu'au Gio pour laisser 
le débit augmenter malgré la latence.


Est-ce que l'explication par le fenêtre trop petite est vraiment la 
bonne pour un trafic tcp wan transatlantique cappé à ~130Mbps ?



Frédéric.

--
Frederic Dumas
f.du...@ellis.siteparc.fr





Bonjour,

iperf3 me fait diagnostiquer un trafic TCP shapé à ~130MBps entre 
iperf.he.net et ma machine. C'est
suffisamment haut pour ne pas poser de problème. Par curiosité, 
est-il possible d'identifier aux

alentours de quel hop le shaping serait appliqué ?


J'ai l'impression que ton problème de TCP shapé n'en est pas un, que 
c'est juste l'effet de la latence que tu mesures...
En effet, faire de l'iperf en TCP, c'est bon pour un LAN ou à la 
limite un WAN national.
Pour la longue distance, si tu veux mesurer une bande passante max, 
c'est forcément avec de l'UDP.




Exacte, aussi si tu veux rester en TCP pour charger un circuit a rtt 
long, multiplie le nombre de flows:


-P, --parallel  # number of parallel client streams to run









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


[FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?

2019-12-12 Par sujet Frederic Dumas



Bonjour,

iperf3 me fait diagnostiquer un trafic TCP shapé à ~130MBps entre 
iperf.he.net et ma machine. C'est suffisamment haut pour ne pas poser de 
problème. Par curiosité, est-il possible d'identifier aux alentours de 
quel hop le shaping serait appliqué ?


D'après le looking glass de HE, les paquets allant de la Californie vers 
l'Europe ne traversent que deux AS: HE et celui de mon FAI (UPC). Ça ne 
nous laisse pas beaucoup de coupables.


Sans sondes le long du chemin, je ne vois pas comment en savoir plus. 
Existe-t-il un outil publiquement accessible du style des sondes Atlas, 
non pas pour regarder les annonces BGP, mais pour tester les débits 
depuis différents points de l'internet? Je préfère poser la question que 
de conclure trop vite.



C'est une question de curiosité, pas un problème réel dans le cas présent.

Bonne journée.



$ iperf3 -t30 -O5 -p5201 -c iperf.he.net -R
Connecting to host iperf.he.net, port 5201
Reverse mode, remote host iperf.he.net is sending

[SNIP]

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-30.00  sec   472 MBytes   132 Mbits/sec0 sender
[  4]   0.00-30.00  sec   473 MBytes   132 Mbits/sec receiver



$ iperf3 -t30 -O5 -p5201 -c iperf.he.net -R -P2
Connecting to host iperf.he.net, port 5201
Reverse mode, remote host iperf.he.net is sending

[SNIP]

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-30.00  sec   456 MBytes   128 Mbits/sec0 sender
[  4]   0.00-30.00  sec   457 MBytes   128 Mbits/sec receiver
[  6]   0.00-30.00  sec   456 MBytes   128 Mbits/sec0 sender
[  6]   0.00-30.00  sec   457 MBytes   128 Mbits/sec receiver
[SUM]   0.00-30.00  sec   912 MBytes   255 Mbits/sec0 sender
[SUM]   0.00-30.00  sec   914 MBytes   256 Mbits/sec receiver



--
Frederic Dumas
f.du...@ellis.siteparc.fr




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


Re: [FRnOG] [TECH] Visio & partage d'écran

2019-12-11 Par sujet Frederic Dumas



Bonjour Alexandre, Wallace,


Un lien vers un produit d'une boîte francaise que j'ai rencontré à 
Lannion : https://www.izeeconf.com/


Je viens de tester, l'ergonomie est très agréable. Ça m'a l'air de 
couvrir toutes les fonctions de whereby.com. Dans ce cas, autant aller 
sur une plateforme française.




Je te conseille vivement JitSi https://meet.jit.si/  open source que
tu peux directement utilisé sur l'url donnée sans authentification ou
on premise.


Le déploiement d'un serveur en propre est recommandé à partir de combien 
d'utilisateurs simultanés ? Quatre comme pour les autres ?



--
Frederic Dumas
f.du...@ellis.siteparc.fr


Le 11/12/2019 à 01:27, Alexandre Moutot a écrit :

Salut Fabien,

Un lien vers un produit d'une boîte francaise que j'ai rencontré à Lannion
: https://www.izeeconf.com/

Alexandre

On Tue, Dec 10, 2019 at 9:45 PM Frederic Dumas 
wrote:



Salut Fabien,

Probablement une réponse plus [BIZ] que [TECH]: whereby.com est une
solution tout terrain, sur tout navigateur, sans pluggin, audio, video,
chat et partage d'écran (ou même partage limité à une fenêtre
d'application seulement). Inconvénient du WebRTC de pair à pair: la
conf. call est limitée à quatre participants. Une version payante
passant par un serveur central autorise jusqu'à 12 participants.

Je n'ai aucune affiliation avec eux, je ne fais que citer ce site pour
l'utiliser depuis longtemps.

Frédéric.

--
Frederic Dumas
f.du...@ellis.siteparc.fr


Le 10/12/2019 à 12:17, Fabien SEGURA a écrit :

J’aurai besoin d’une solution avec un client qui tourne sur tout type de
bécanne sans avoir besoin d’installer de pluggin, l’idée étant que les
invités puissent accéder aux conférences facilement et rapidement depuis
n’importe où (tout le monde n’a pas les droits d’admin sur son PC).







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


Re: [FRnOG] [TECH] Visio & partage d'écran

2019-12-10 Par sujet Frederic Dumas



Salut Fabien,

Probablement une réponse plus [BIZ] que [TECH]: whereby.com est une 
solution tout terrain, sur tout navigateur, sans pluggin, audio, video, 
chat et partage d'écran (ou même partage limité à une fenêtre 
d'application seulement). Inconvénient du WebRTC de pair à pair: la 
conf. call est limitée à quatre participants. Une version payante 
passant par un serveur central autorise jusqu'à 12 participants.


Je n'ai aucune affiliation avec eux, je ne fais que citer ce site pour 
l'utiliser depuis longtemps.


Frédéric.

--
Frederic Dumas
f.du...@ellis.siteparc.fr


Le 10/12/2019 à 12:17, Fabien SEGURA a écrit :

J’aurai besoin d’une solution avec un client qui tourne sur tout type de
bécanne sans avoir besoin d’installer de pluggin, l’idée étant que les
invités puissent accéder aux conférences facilement et rapidement depuis
n’importe où (tout le monde n’a pas les droits d’admin sur son PC).






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


[FRnOG] [TECH] Checkpoint R77.20 - drop de paquets etrangers au LAN en mode bridge

2019-12-04 Par sujet Frederic Dumas



Bonjour à tous,

C'est un peu la suite des aventures de cette route statique annoncée en 
option 121 par le DHCP d'un CheckPoint (cf. début novembre ici sur la 
liste). Elle permet aux machines locales d'accéder à celles d'un 
sous-réseau distant à travers une passerelle située sur le LAN, qui 
n'est pas la passerelle par défaut. Au final, tout a bien voulu fonctionner.



On a un peu changé la topologie du LAN:


 - la passerelle en question était jusqu'à présent placée dans le même
   VLAN que les autres postes du LAN, en amont du CheckPoint;

 - elle a été changée de VLAN, pour être isolée sur un port Ethernet
   du CheckPoint, qui lui soit réservé;

 - sur le CheckPoint, un bridge remet ensemble ce port Ethernet dédié à
   la passerelle et le port Ethernet dédié au reste des machines du LAN;

 - cette topologie a pour but de permettre le filtrage sur MAC address
   par le CheckPoint (dispo en mode bridgé seulement).


On observe alors un comportement difficile à expliquer par la théorie:


 - la passerelle est parfaitement accessible à son adresse IP locale;
   depuis le LAN (de l'autre coté du bridge donc), on la pingue, elle
   répond, on se logue sans problème, normal, on est sur un bridge;

 - par contre, toujours depuis le LAN, on a perdu la connectivité avec
   les machines distantes, situées sur le sous-réseau accessible par la
   passerelle ?!?


Après quelques vérifications, il apparait que:


 - les requêtes vers les machines distantes sont bien acheminées par la
   passerelle; elles traversent donc le bridge;

 - les réponses parviennent à la passerelle, qui les émet sur son
   interface, de son coté du bridge;

 - malheureusement, tcpdump est formel: de l'autre coté du bridge, sur
   le reste du LAN, le CheckPoint ne transmet aucun des paquets sortant
   de la passerelle, dès lors que ceux-ci ont des machines
   distantes pour adresse d'origine;

 - pour fermer la porte à une fausse piste, le phénomène se produit
   aussi bien lorsque le filtrage sur MAC address est activé ou
   désactivé sur le CheckPoint;

 - cependant, comme dit plus haut, le CheckPoint transmet bien sur le
   bridge tous les paquets émis par la passerelle, dès lors que ceux-
   ci ont pour adresse d'origine celle de la passerelle elle-même.

Si on essaye de "tirer dans le noir" comme disent les anglo-saxons, ça 
fait penser à une règle d'anti-spoofing qui droperait les paquets de 
retour, car ils ont une adresse d'origine extérieure au LAN. Mais rien 
ne le confirme dans les logs du CheckPoint. Les paquets ont disparus, et 
c'est tout.


Bug ou feature ? Y-a-t-il un moyen de configurer le CheckPoint pour 
contourner ce problème ? Une route à déclarer pour contourner le filtre 
anti-spoofing, pour autant que ce soit lui la cause ?



Merci pour vos conseils ou hypothèses.



--
Frederic Dumas
f.du...@ellis.siteparc.fr






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


Re: [FRnOG] [TECH] [Resolu] Checkpoint R77.20 - route statique par DHCP - RFC3442

2019-11-07 Par sujet Frederic Dumas



Merci pour tes explications détaillées Patrick.

Dans l'exemple cité, on comprend que le "12" situé au milieu de la 
valeur de l'option 121 ne désigne pas le nombre d'octets encodant la 
seconde route, comme Michel a pu en faire l'hypothèse, mais désigne le 
masque de la seconde route.


Pour finir, est-ce qu'on comprend aussi que chaque annonce option 121 
permet d'annoncer plusieurs routes accessibles par une même passerelle, 
mais pas plusieurs passerelles ? Pour cela, suffit-il de faire répéter 
au serveur DHCP l'option 121 avec des valeurs différentes dans chaque 
annonce ?


Frédéric.

--
Frederic Dumas
f.du...@ellis.siteparc.fr


Le 07/11/2019 à 15:51, Michel Py a écrit :


Quand je lis RFC3442, je ne vois pas ou mettre le "12". Dans
Destination 2, il n'y a pas de "Len", pas de "n", ce qui laisserait
supposer que n est la même valeur pour toutes les destinations. Tu
mettrais quoi comme valeur, en se basant sur RFC3442 ?


Le 07/11/2019 à 16:17, Patrick Maigron a écrit :


- 12 172 16 192 168 248 251
La longueur du préfixe est 12, il y a donc 2 octets significatifs pour
le préfixe, donc 172 16 -> 172.16.0.0/12
Destination2 : 12 172 16








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


Re: [FRnOG] [TECH] [Resolu] Checkpoint R77.20 - route statique par DHCP - RFC3442

2019-11-07 Par sujet Frederic Dumas



Bonjour Michel,
Bonjour à tous,


Le 06/11/2019 à 20:48, Michel Py a écrit :
Malheureusement je ne connais rien au Checkpoint, mais j'utilise 
cette option (121) et çà marche impec avec des clients Windows.



On tient la solution. Le CheckPoint transmet bien l'option 121 dans sa 
réponse DHCPACK. Par conséquent, la route statique est désormais bien 
acquise par nos stations de travail. Le problème des paquets martiens 
est résolu.



La difficulté était de découvrir la syntaxe à utiliser sur le 
CheckPoint, pour y enregistrer cette route statique au format RFC3442.



Exemple:
route statique 192.168.37.0/24
passerelle 192.168.248.251


D'après la RFC3442, la valeur de l'option 121 doit être codée ainsi:

   24 192 168 37 192 168 248 251


L'interface utilisateur web du CheckPoint semble offrir le choix entre 
deux options, dans la fenêtre "DHCP Custom option":



 - Hex String:

La valeur de l'option 121 doit alors être saisie en hexadecimal ; le 
CheckPoint ne réalise aucune conversion et transmet les 8 octets en 
l'état (moins leurs séparateurs) dans le corps du paquet DHCPACK:


   saisi à la main:
   18:C0:A8:25:C0:A8:F8:FB

   envoyé par le CheckPoint:
   18c0a825c0a8f8fb

Dans la saisie manuelle, le séparateur entre les octets est le 
deux-points, et il n'y a pas de séparateur entre l'adresse de réseau et 
celle de la passerelle.



 - IP Address Array

La valeur de l'option 121 doit alors être saisie en base 10 classique, 
et sera convertie par le CheckPoint en octets dans le corps du paquet 
DHCPACK:


   saisi à la main:
   24.192.168.37,192.168.248.251

   envoyé par le CheckPoint:
   18c0a825c0a8f8fb

Dans la saisie manuelle, le séparateur entre les chiffres est le point 
et le séparateur entre l'adresse de réseau et celle de la passerelle est 
la virgule.



Dans tous les cas, le CheckPoint calcule lui-même la longueur de 
l'option 121 (ici, huit octets, mais ça pourrait différer en fonction du 
masque de réseau et du nombre de passerelles annoncées). Il ne faut pas 
la saisir manuellement.



Comme pour l'oeuf de Christophe Colomb, rien de compliqué une fois qu'on 
sait comment enregistrer ces valeurs dans l'interface du firewall. Le 
problème, c'est le silence complet de la doc CheckPoint à ce sujet. Le 
man de dhcpd-options fut mon ami:


https://linux.die.net/man/5/dhcpd-options



Ci-dessous, le DHCPdump qui confirme la présence de l'option 121 dans 
les paquets DHCPACK émis par le CheckPoint:




OPTION:  57 (  2) Maximum DHCP message size 1500
OPTION:  61 (  7) Client-identifier 01:c8:2a:14:xx:xx:xx
OPTION:  50 (  4) Request IP address192.168.248.64
OPTION:  51 (  4) IP address leasetime  7776000 (12w6d)
OPTION:  12 ( 15) Host name WorkStation
---

  TIME: 2019-11-07 10:12:00.946
IP: 192.168.248.254 (0:1c:7f:xx:xx:xx) > 192.168.248.64 
(c8:2a:14:xx:xx:xx)

OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 5c407f63
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 192.168.248.64
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: c8:2a:14:xxx:xx:xx:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type 5 (DHCPACK)
OPTION:  54 (  4) Server identifier 192.168.248.254
OPTION:  51 (  4) IP address leasetime  921600 (1w3d16h)
OPTION:   1 (  4) Subnet mask   255.255.255.0
OPTION: 121 (  8) Classless Static Route18c0a825c0a8f8fb ...%
OPTION:   3 (  4) Routers   192.168.248.254
OPTION:   6 (  4) DNS server192.168.248.254
---



En espérant que ça puisse aider quelqu'un d'autre.


--
Frederic Dumas
f.du...@ellis.siteparc.fr


Frederic Dumas a écrit :

Quelqu'un pourrait-il m'aider à encoder l'annonce d'une route statique
au format RFC3442 dans le "DHCP Custom option" du Checkpoint ?




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


Re: [FRnOG] [TECH] Checkpoint R77.20 - route statique par DHCP - RFC3442

2019-11-06 Par sujet Frederic Dumas



Réponse courte:

Quelqu'un pourrait-il m'aider à encoder l'annonce d'une route statique 
au format RFC3442 dans le "DHCP Custom option" du Checkpoint ?



Réponse normale:

Bonjour David,
Bonjour Radu,


Le 06/11/2019 à 12:04, David Ponzone a écrit :
Sinon, si les PC du LAN voit la passerelle en question, le 
Checkpoint la voit aussi, donc pourquoi tu mets juste pas une route

statique dans le Checkpoint vers ce sous-réseau avec la passerelle en
question comme next-hop ?


Oui, c'est ce que nous avions commencé à faire. Grâce aux annonces ICMP 
Redirect émises par le Checkpoint, nos stations de travail dirigent 
effectivement vers la passerelle en question le trafic destiné à ce 
sous-réseau particulier. De l'autre coté de la passerelle, les serveurs 
nous répondent. Tout devrait donc bien aller.


Mais alors...


Le 06/11/2019 à 12:18, Radu-Adrian Feurdean a écrit :


Parce-que routage asymetrique qui interfere avec le statefull firewall.



Le 06/11/2019 à 12:37, David Ponzone a écrit :

Il y a peut-être un moyen de couper le firewall pour le trafic
LAN<—>LAN.


Bien tenté, la vérité est pourtant encore ailleurs, mes chers Sculley et 
Mulder :-)


Nos stations de travail reçoivent les réponses des serveurs situés 
au-delà de la passerelle en question, car elles empruntent le même 
chemin au retour qu'à l'aller. Tout va bien. Mais comme ces paquets 
proviennent d'une passerelle vers laquelle les stations de travail n'ont 
pas de route par défaut, nos stations de travail considèrent alors ces 
paquets entrant comme des paquets martiens et... les droppent.


Le phénomène est identique sur Linux, OS.X et Windows. Ce qu'il faut à 
nos stations de travail, c'est une route statique définie sur chacune 
d'elles, vers la passerelle en question.


D'où l'idée de charger le serveur DHCP du Checkpoint de la tache 
d'annoncer cette route statique.



Je reviens donc à ma question d'origine: quelqu'un pourrait-il m'aider à 
encoder l'annonce d'une route statique au format RFC3442 dans le "DHCP 
Custom option" du Checkpoint ?



En remerciant d'avance les plus chenus d'entre nous.


--
Frederic Dumas
f.du...@ellis.siteparc.fr


Le 06/11/2019 à 11:46, Frederic Dumas a écrit :


Bonjour à tous,

Peut-on configurer un Checkpoint 600 (firmware R77.20.80) pour que son 
serveur DHCP annonce à nos stations de travail une route statique vers 
un sous-réseau inaccessible par le Checkpoint, mais accessible par une 
autre passerelle, située sur le même sous-réseau que les stations de 
travail ?


Je n'ai pas vu comment ajouter de routes statiques dans la configuration 
DHCP du Checkpoint; le "DHCP custom option" le permet-il ? Le guide de 
l'admin R77 n'apporte pas de réponse. Est-ce le moyen d'enregistrer une 
route statique au format RFC3442 [1] ? Si oui, quelqu'un peut-il m'aider 
pour la syntaxe exacte à utiliser ?



Merci pour votre aide.

Frédéric.


[1] https://tools.ietf.org/html/rfc3442
--
Frederic Dumas
f.du...@ellis.siteparc.fr








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


[FRnOG] [TECH] Checkpoint R77.20 - route statique par DHCP - RFC3442

2019-11-06 Par sujet Frederic Dumas



Bonjour à tous,

Peut-on configurer un Checkpoint 600 (firmware R77.20.80) pour que son 
serveur DHCP annonce à nos stations de travail une route statique vers 
un sous-réseau inaccessible par le Checkpoint, mais accessible par une 
autre passerelle, située sur le même sous-réseau que les stations de 
travail ?


Je n'ai pas vu comment ajouter de routes statiques dans la configuration 
DHCP du Checkpoint; le "DHCP custom option" le permet-il ? Le guide de 
l'admin R77 n'apporte pas de réponse. Est-ce le moyen d'enregistrer une 
route statique au format RFC3442 [1] ? Si oui, quelqu'un peut-il m'aider 
pour la syntaxe exacte à utiliser ?



Merci pour votre aide.

Frédéric.


[1] https://tools.ietf.org/html/rfc3442
--
Frederic Dumas
f.du...@ellis.siteparc.fr



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


Re: [FRnOG] [TECH] Messagerie outlook.com

2019-07-19 Par sujet Frederic Robert

On 7/18/19 1:37 PM, François Otho wrote:


Me doutant que le problème ne pouvait provenir que de notre serveur (ou de son ip qui est 
"nouvelle").
Ce matin j'ai envoyé les emails sur un autre relais; tout le traffic est sorti 
sans encombre par cet autre serveur.

A 14h , j'ai remis en service le serveur initial , et tout le traffic sort s'en 
encombre pour l'instant.


Bonjour,

Comment allez-vous? J'ai remarqué que parfois microsoft supprime 
silencieusement les messages à l'arrivée. Malgré sent dans le serveur 
postfix. Avez-vous déjà eu ce problème?


Bonne journée,

--
Frederic Robert


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


Re: [FRnOG] [MISC] Activation internet la plus longue de l'histoire - annul. prelev.

2019-05-25 Par sujet Frederic Dumas



Bonjour Eugène,
Bonjour à tous,


Sauf qu'à ma grande surprise je constate un prélèvement de *311,25€* sur
mon compte ce weekend, de la part de Coriolis, je ne comprends rien et ce
matin je viens d'avoir une de leurs agents au téléphone,


[SNIP]


Ayant mon RIB ils se sont servis, tout simplement.


Tu le sais probablement, si tu considères ce prélèvement infondé, tu 
disposes de trois mois pour donner ordre à ta banque de recréditer ton 
compte de la somme prélevée, sans avoir à motiver ta demande. Chez moi, 
la procédure se réduit à un simple bouton "Remboursement" à cliquer dans 
l'interface web. D'expérience, la banque s'exécute sans discussion.


A partir de là, et en attendant le déroulement de ton affaire, le 
système de facturation de Coriolis ne pourra pas faire grand chose 
d'autre que de t'envoyer du papier, que tu pourra probablement ignorer 
en toute sécurité.


Il est préférable de récupérer ton argent et de discuter ensuite, les 
gros ayant tendance à jouer le pourrissement vis-à-vis du petit dès lors 
qu'ils ont encaissé.


Désolé d'ajouter cette info à une discussion déjà ancienne, je rattrape 
du retard en lecture.


Bye.

--
Frédéric Dumas
f.du...@ellis.siteparc.fr


Le 02/04/2019 à 11:30, Eugène Ngontang a écrit :

Bonjour,

Toujours dans mes déboires avec Coriolis, j'ai porté plainte depuis un
moment comme je disais, ils ont continué à faire le malin, et donc y a une
assignation qui est partie, et j'attends la convocation du tribunal de
grande instance de Paris.

Ils ont fini par lever la main sur mon dossier là en fin du mois de
février, et ma ligne est active chez K-net depuis la semaine dernière.

Sauf qu'à ma grande surprise je constate un prélèvement de *311,25€* sur
mon compte ce weekend, de la part de Coriolis, je ne comprends rien et ce
matin je viens d'avoir une de leurs agents au téléphone, elle me dit après
avoir vérifié avec l'équipe de déploiement, que (d'après Coriolis) j'ai
résilié ma commande après le déploiement de le fibre par COVAGE, et donc je
dois payer les frais de résiliation. Ayant mon RIB ils se sont servis, tout
simplement.

Je demande le 3 janvier, après plus de trois mois de galère où je me fais
trimballer dans tous les sens, d'arrêter tout et d'annuler la commande,
Coriolis me confirme l'annulation le 7 janvier en m'envoyant l'adresse de
retour du matériel (dont je n'avais jamais ouvert les cartons), je renvoie
le matériel en bonne et due forme avec les frais que ça comporte et accusé
de réception par chronopost, je confirme auprès de K-net que c'est bon,
COVAGE fait le déploiement de ma ligne le 29 janvier avant de constater
lors de l'activation que la commande à leur niveau est encore au nom de
Coriolis... blablabla, et Coriolis me dit que ce jour je devais interdire à
COVAGE de faire le déploiement, car je n'avais pas résilié la commande. Non
ils veulent ma tête les mecs !

Je ne sais pas si c'est moi qui débarque mais je me demande bien si cette
boîte pratique la sorcellerie, je n'ai jamais vu une telle gestion de la
relation "client" (encore qu'au final je n'ai jamais été client) de toute
mon experience.;

Voilà je vous donnais juste des nouvelles, je laisserai la justice faire et
j'ai du temps pour cela (j'en trouverai), je pense que Coriolis n'a pas
encore croisé le chemin d'un particulier qui ne laisse pas marcher dessus.

Bonne journées les guru, et bonne semaine.

Cordialement,
Eugène NG



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


Re: [FRnOG] [BIZ] Protection DDOS Cloud

2019-04-10 Par sujet Frederic Billy
Bonjour, 

Vous pouvez creuser aussi la solution Acorus Networks.

Le contact est le suivant : 

Olivier Melwig
oliv...@acorus-networks.com
www.acorus-networks.com
FR: +33 6 2766 2475
UK: +44 7447 300 244

Au plaisir.

Frédéric BILLY
Sipartech

Le 10/04/2019 16:15, « frnog-requ...@frnog.org au nom de Thib D » 
 a écrit :

Bonjour,

je suis actuellement à la recherche d'un fournisseur pour assurer de la
protection et auto mitigation DDoS sur des services Cloud. Nos services
seront sur une infrastructure Anycast dans 2 AS distincts et sur nos
propres ressources IP.

Avez-vous des retours sur les principales solutions (ex : Arbor/radware ?)
ou éventuellement d'autres pistes à proposer pour ce genre de service?

Merci.

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



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


Re: [FRnOG] [MISC] la porte derobee des serveurs Supermicro

2019-01-14 Par sujet Frederic Dumas



Continuant la discussion d'octobre sur le "hack chinois" rapporté par 
Bloomberg dont les cartes mères Supermicro auraient été victimes, voici 
une très récente contribution sur la faisabilité technique de la 
contamination du BMC par implant d'un composant actif à la place d'une 
résistance, sur une des lignes entre la mémoire flash et le BMC d'un 
serveur Supermicro.


L'auteur a présenté à Leipzig fin 2018 une preuve de concept sur FPGA, 
lui permettant d'altérer à la volé le code lu par le BMC au démarrage du 
serveur, pour parvenir à afficher quelques caractères sur le port console.




And that is what this proof of concept hardware implant on the BMC SPI
bus does: it replaces one of the empty regions with a new inode that
overwrites the /nv/network/netconfig2 file with its own shell script,
since the /etc/rc.d/55ipmi.sh script will execute it as a subshell.
This PoC doesn't do much, other than print a message to the serial
console to indicate that it has achieved code execution during the boot
process. 


Source: https://trmm.net/Modchips


Le reste de son article présente différentes hypothèses pour tenter de 
distinguer si cette annonce était un fausse ou non. Sa conclusion est 
prudente. Mais la quantité d'hypothèses passées en revue mérite d'être lue.



Du point de vue hardware, la partie la plus intéressante de son article 
est celle où il décrit comment l'implant devrait collecter l'énergie 
nécessaire à son fonctionnement par couplage capacitif, reconstituer le 
signal d'horloge, écouter en permanence pour détecter la transmission, 
etc. Ceci afin de ne pas devoir être connecté à d'autres lignes du PCB 
que celle unique sur laquelle se trouve être normalement implantée la 
résistance.



Normally the SPI bus requires six connections to function, but the
implant has only part of a single one. It doesn't connect to power or 
ground, so it must be parasitically powered by the current flowing 
from the SPI flash to the BMC during normal operation (similar to the 
RFID CPUs that have enough capacitance to run even when they are 
shorting the antenna coil). It doesn't have access to the chip select 
line, so it has to guess when the chip is being read. It doesn't have 
access to the clock line, so it has to guess the clock frequency. It
doesn't have access to the Serial Data In (SI or MOSI), so it has to 
monitor the SO data to try to recognize where in the flash the BMC is 
reading. And, due to the way it is constructed and powered, it can't 
generate arbitrary bit patterns, it can only disconnect the line and
turn 1 bits into 0 bits. A simple matter of engineering to work around 
these, right? 


Souce: idem


--
Frédéric Dumas
f.du...@ellis.siteparc.fr



Le 05/10/2018 à 08:23, Alexandre DERUMIER a écrit :

un article un peu plus technique:

https://www.theregister.co.uk/2018/10/04/supermicro_bloomberg/

"The spy chip could have been placed electrically between the baseboard management 
controller (BMC) and its SPI flash or serial EEPROM storage containing the BMC's 
firmware. Thus, when the BMC fetched and executed its code from this memory, the spy chip 
would intercept the signals and modify the bitstream to inject malicious code into the 
BMC processor, allowing its masters to control the BMC."

Ca serait donc au niveau de la bmc.

Après est-ce que c'est exploitable si la bmc n'est pas accessible sur le net ?
vu la taille du chip, ca semble difficile d'implémenter un exploit ou autre 
autonome.



- Mail original -
De: "Michel Py" 
À: "frnog-misc" 
Envoyé: Vendredi 5 Octobre 2018 00:39:10
Objet: [FRnOG] [MISC] la porte dérobée des serveurs Supermicro

Un troll de luxe pour ce vendredi !

https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies

En bref : les carte mères de serveurs Supermicro contiennent un composant conçu 
par les services de renseignements Chinois qui permettrait de prendre le 
contrôle du serveur. Comme un root kit, mais dans le matériel.

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] [MISC] Nouvelle loi en Australie: les entreprises doivent permettre aux autorités de casser n'importe quel chiffrement

2018-12-16 Par sujet Frederic Dumas



Bonjour Barth,
bonjour à tous,


> Je viens de voir passer sur Reddit un thread qui a l'air assez
> impactant niveau sécurité:
> 
https://www.reddit.com/r/programming/comments/a3kk7u/australian_programmers_could_be_fired_by_their/



L'Australie faisant partie des Five Eyes, ce que l'ASD australien voit, 
la NSA américaine le voit vraisemblablement aussi.


On peut penser que l'Australie a été choisie comme tête de pont pour 
légaliser l'accès aux "transmissions" des agences de surveillance, mais 
qu'en réalité, ce sont les Etats-Unis qui sont à la manœuvre et 
souhaitent ces changements législatifs, chez eux et chez leurs satellites.



Entre :

> une loi contraignant les entreprises (snip) à implémenter dans leurs
> produits une possibilité pour les autorités australiennes de
> déchiffrer n'importe quelle communication.

et :

> La loi "n'impose pas" de backdoor,

Il semble y a voir une contradiction. Mettre par exemple une clé tierce 
sous séquestre me semble être une forme de backdoor.



Je me rappelle de l'avocat de Wikileaks qui expliquait :

«… toute entreprise française, participant à un appel d’offre supérieur 
à 250 millions d'euros, n’importe où dans le monde, est systématiquement 
espionnée par la NSA, afin de saboter leur offre. Combien de milliers 
d’emplois ont été détruits à cause de ces dispositifs ? »


Source : https://www.youtube.com/watch?v=uBaAvHxdShw=3653


Ce qui est vrai pour une entreprise française l'est pour celle d'un 
autre pays. Là est sans doute une des explications de la direction dans 
laquelle poussent les Etats-Unis.



--
Frédéric Dumas
f.du...@ellis.siteparc.fr



Le 06/12/2018 à 18:52, Barthélémy DELUY a écrit :

Bonjour à tous,

Je viens de voir passer sur Reddit un thread qui a l'air assez impactant
niveau sécurité:
https://www.reddit.com/r/programming/comments/a3kk7u/australian_programmers_could_be_fired_by_their/

Apparemment, les deux chambres du parlement australien ont voté aujourd'hui
une loi contraignant les entreprises (étrangères ou australiennes) faisant
du business avec des entités (privées ou publiques) australiennes à
implémenter dans leurs produits une possibilité pour les autorités
australiennes de déchiffrer n'importe quelle communication. Sont ciblés les
GAFA mais pas seulement, toute société disposant d'un produit utilisant du
chiffrement devra se conformer à cette législation.
La loi "n'impose pas" de backdoor, mais fait risquer plusieurs années de
prison à toute personne physique ou morale qui refuserait de se plier à la
demande des autorités (les commentateurs du thread et les journalistes de
l'article lié indiquent clairement que les autorités vont cibler
individuellement les développeurs pour qu'ils installent des faiblesses à
l'insu de leurs employeurs).

Des risques que ce genre de loi soit véritablement appliquée ?

Il y en a parmi vous qui travaillent avec des sociétés australiennes ou qui
utilisent des produits développés dans ce pays ? Quels risques selon vous
sur votre activité ?
Par exemple, Atlassian (Jira, Bitbucket, sourceTree, Trello) est une
société australienne qui devra se conformer à cette législation...

Barth

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




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


[FRnOG] [Tech] Seagate "hyperscale"

2018-11-09 Par sujet Frederic Dumas



Une question destinée aux membres de la liste qui auraient rencontré ces 
disques durs dans leurs baies. Il s'agit des modèles chez Seagate :


ST1NM0086

et

ST1NM0016





La seule différence entre ces deux modèles tiendrait à leur firmware. Le 
premier serait "standard", l'autre "hyperscale"/"ultra-évolutif"). Le 
firmware "hyperscale" offrirait 20% d'IOPS en plus. En contrepartie, 
présente-t-il certains inconvénients ?



Quelqu'un a-t-il en sait-il plus sur le sujet ?


--
Frédéric Dumas
f.du...@ellis.siteparc.fr


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


Re: [FRnOG] [TECH] Export/Import configuration Mikrotik

2018-10-26 Par sujet Frederic Hermann
Je confirme que c'est pas toujours évident. 
Je n'ai jamais réussi à charger automatique un .rsc après un 
reset-configuration.

Du coup on génère et on déploie des .rsc a partir de templates jinja2 via 
ansible, et c'est très bien comme ça. 

Lors d'un export (et même d'un backup), il faut faire attention aux 
certificats. S'il y a des clés privées installées dans /certificates, un export 
en clair ne les exportera pas. 

mes 2cts

- Mail original -
> De: "Hugues Voiturier" 
> À: "David Ponzone" 
> Cc: "Sébastien 65" , frnog-t...@frnog.org
> Envoyé: Vendredi 26 Octobre 2018 14:12:30
> Objet: Re: [FRnOG] [TECH] Export/Import configuration Mikrotik

> Nous on vire la conf par défaut en cli ouais, avec mac-telnet ça se fait super
> vite dans un script.
> Et oui, Winbox marche avec 0 conf, il suffit de s’y connecter via la MAC.


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


Re: [FRnOG] [MISC] 06 ABPQ - portage vers operateur VoIP ? [Oui c'est possible]

2018-10-25 Par sujet Frederic Dumas



Merci Nicolas pour votre réponse précise.

Comme quoi rien de tel que de poser la question à ceux qui en 
connaissent, plutôt que de se persuader que "ça n'est pas possible, 
puisque ça ne s'est jamais fait".


Merci à Richard et Olivier aussi, pour les infos immédiatement 
utilisables que vous m'avez données.


Frédéric.

--
Frédéric Dumas
f.du...@ellis.siteparc.fr


Le 25/10/2018 à 09:44, Nicolas Bougues a écrit :

Ce cas n'était pas vraiment prévu par la réglementation jusqu'à maintenant
(même si certains MVNOs notamment avaient des offres plus ou moins
approchantes, cf autres posts), mais c'est chose faite depuis cet été avec
la décision ARCEP 2018-0881 sur les nouvelles règles du plan de
numérotation qui prévoit dorénavant l'existence d'opérateurs mobiles basés
sur VoIP (et donc non sur un PLMN).

Ce genre d'offre devrait donc se développer.

Le mer. 24 oct. 2018 à 18:46, Frederic Dumas  a
écrit :



Bonjour,

En France, la réglementation permet-elle de porter un numéro de
téléphone mobile vers un opérateur VoIP ? Je m'attends à une réponse
négative, mais peut-être existent des cas particuliers ?

Le but serait de réunir sur un seul abonnement 4G data, sans service
voix, différentes lignes mobiles et fixes, toutes terminées en VoIP.



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


[FRnOG] [MISC] 06 ABPQ - portage vers operateur VoIP ?

2018-10-24 Par sujet Frederic Dumas



Bonjour,

En France, la réglementation permet-elle de porter un numéro de 
téléphone mobile vers un opérateur VoIP ? Je m'attends à une réponse 
négative, mais peut-être existent des cas particuliers ?


Le but serait de réunir sur un seul abonnement 4G data, sans service 
voix, différentes lignes mobiles et fixes, toutes terminées en VoIP.


Merci.

--
Frédéric Dumas
f.du...@ellis.siteparc.fr


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


Re: [FRnOG] [TECH] mini serveur domestique

2018-10-15 Par sujet Frederic Dumas



Pour un usage NAS/NextCloud à la maison, un peu comme ce que décrit 
Elonga, je voudrais reconvertir un vieux Juniper, conserver son boîtier 
1U, et remplacer sa carte mère FlexATX.


La carte que tu as choisi, Olivier, quel est son format ? Probablement 
au moins mini-ATX vu le nombre de ports que tu décris.


Dans quel format compatible avec la visserie FlexATX j'aurai le plus de 
chance de trouver sur le marché des cartes serveur SOHO de petite taille 
revendues d'occasion ?


--
Frédéric Dumas
f.du...@ellis.siteparc.fr


Le 14/10/2018 à 19:34, Olivier Lange a écrit :

3VM sur un raspberry? Ca devient chaud. Surtout que l'on est pas en x86,
mais en ARM.

De mon coté, j'ai pris une carte mère avec pas mal de bord Sata (j'ai 5
disques de 4To en Raid 5 dessus), sur base AMD (moins cher que de l'intel
et parfait pour de la virtu), 16Go de RAM. Et avec un
proxmox/KVM/VMWare/Xen selon tes préférences, tu monde ce que tu veux.

Mais commencer a vouloir cumuler virtu, stockage, pas cher et resapberry,
il y a 1, voir 2 paramètres qui sautent...

Olivier

Le dim. 14 oct. 2018 à 18:56, elonga bopeto  a
écrit :


Merci pour vos retours.
Après un rapide tour sur le site de synology, il semblerait que seuls
quelques os soient supportés en virtualisation. Pas de fortigate ni vyatta
ni pfsense...

Quand aux raspberry et consorts, il est possible d'y installer un
hyperviseur bare metal afin d'y virtualiser à minima 3 vm?



Le dim. 14 oct. 2018 à 18:37,  a écrit :


Un syno + son gestionnaire de vm (intégré) = solution domestique parfaite
:)


*Kevin LABECOT*
Responsable Infrastructure
Service Informatique

*1001pneus* 
4/6 cours de l'intendance
33000 Bordeaux

*Envoyé depuis mon mobile* *Tel:* 05 35 54 31 10
*Mob:* 06.08.46.96.50
*Fax:* 01.83.64.28.70
*E-mail:* kevin.labe...@1001pneus.fr


Le 14 oct. 2018 à 18:26 +0200, Guillaume Tournat ,
a écrit :

En solution à la maison, j’ai un Synology
Ça permet de faire plein de choses


Le 14 oct. 2018 à 18:10, elonga bopeto  a écrit :

Bonjour la communauté,

Je cherche une solution silencieuse, faible encombrement, faible
consommation électrique et faible coup, afin de faire tourner quelques
services à mon domicile.
Je pense à un NAS pour backuper google drive/photo, un serveur web et un
reverse proxy ainsi qu' un firewall pour sécuriser le tout (VM Fortigate
ou
Vyatta ou pfsense ou d'autres...)
Il me servira également à réaliser mes labs.

Quel solution physique, logicielle et architecture me conseillerez-vous?

Merci pour vos retours

Cordialement,
Elonga

---
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] Les AS privés dans les AS-PATH

2018-06-05 Par sujet Frederic Dhieux


Le 04/06/2018 à 16:37, Clement Cavadore a écrit :
> On Mon, 2018-06-04 at 16:22 +0200, Julien Escario wrote:
>> A priori, ca n'a pas d'intérêt ni bon, ni mauvais si ce n'est
>> d'allonger artificiellement l'AS-PATH. Ceci dit, on est d'accords que
>> ca ne devrait pas sortir d'un AS ce genre de truc ?
>>
>> Vous filtrez ça ?
> Oui, et je t'encourage à le faire.
> Si jean-kevin ne sait pas configurer proprement ses routeurs, il y a
> fort a parier que tu ne veux pas voir ses annonces dans ta RIB/FIB :-)
Hello,

Ouais c'est bien le discours radical "il fait ça mal, il mérite pas que
j'apprenne ses routes", sauf que c'est arrivé parfois aussi à des gros
FAI français par exemple qui découpent leur réseau par zones comme ça et
oublient le remove-private-as, ça peut arriver à un petit qui a juste
loupé une ligne de conf. L'erreur est humaine, ce serait bien que ce
soit remonté par quelque système de suivi, mais je ne trouve pas que ce
soit matière à "bannir" un préfixe quand même (tant que ce n'est pas
l'AS final de l'as-path).

C'est mignon en plus, ça permet de vanner les gens un peu :D

Frédéric


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


Re: [FRnOG] [MISC] Quel outil opensource et sexy pour le suivi des demandes utilisateurs ?

2018-05-24 Par sujet Frederic Hermann



> De: "Jérôme Quintard" 
> Objet: [FRnOG] [MISC] Quel outil opensource et sexy pour le suivi des 
> demandes utilisateurs ?

> Bonjour à tous,

> Quelqu'un aurait un help desk sexy, rapide, à installer et opensource à me
> présenter ?

iTop, dont on a déja parlé ici, c'est pas super rapide a mettre en place, mais 
ça gère les demandes utilisateurs (si on installe le module helpdesk), et c'est 
couplé à la CMDB. 

Pour les utilisateurs le portail est simpliste (et donc sexy). 
Pour les opérateurs de l'autre côté ... c'est un peu moins sexy mais ça se 
gère. 

Par contre ca gère (si on veut) la différence entre demande utilisateur, 
gestion des problèmes, gestion des changements à la sauce ITIL. 

Pour le reporting, il y a des tableaux de bord basiques. 

Et sinon, pour faire juste du ticket, RT (Request Tracker) ça fait le job 
aussi. 





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


Re: [Newsletter] Re: [FRnOG] [TECH] UTM pour SMB ?

2018-05-12 Par sujet Jean-Frederic Karcher
Bonjour,

Fortinet me semble bien plus approprié à tes exigences car il couvre 
l’intégralité des besoins (voire davantage même) pour un prix bien inférieur 
lorsque l’on compare les specs de débit par exemple.
A dispo si besoin de davantage d’info ou de contacts appropriés chez Fortinet

Cdt, JFK

Jean-Frederic KARCHER


> Le 12 mai 2018 à 14:37, Clément Guivy <clem...@guivy.fr> a écrit :
>
>> On 12/05/2018 12:47, Mathieu Poussin wrote:
>> Concou misters et misses
>> Je suis a la recherche d'un UTM ( ou comme ils disent Next Generation 
>> Firewall ) pour remplacer notre EdgeRouter qui montre ses limites dans ce 
>> domaine.
>
> Salut, palo alto me semble faire tout ce que tu demandes (modulo la partie 
> endpoint, je ne connais pas ce sujet donc je ne peux pas te dire), si tu es 
> prêt à faire une concession sur le débit VPN IPSec tu peux partir sur du 
> PA-820 ou 850 qui restent abordables
> , ou s'il te faut absolument du >1Gbps IPSec il y a le 3220 mais sensiblement 
> plus cher. Après je ne sais pas ce que tu veux dire pas "pas hors de prix", 
> c'est assez vague :)
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are 
hereby notified that any review, use, disclosure, dissemination, distribution 
or copying of this message and any attachments is strictly prohibited. If you 
have received this email in error, please immediately notify the sender and 
destroy this e-mail and any attachments and all copies, whether electronic or 
printed. Please also note that any views, opinions, conclusions or commitments 
expressed in this message are those of the individual sender and do not 
necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are 
not binding on Fortinet and only a writing manually signed by Fortinet's 
General Counsel can be a binding commitment of Fortinet to Fortinet's customers 
or partners. Thank you. ***



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


Re: [FRnOG] [TECH]Captive portal, WiFi et IPv6 : des solutions ?

2018-05-07 Par sujet Frederic Hermann

> Mon problème est de maintenir un lien entre les credentials utilisés sur 
> le captive portal et toutes les adresses IPv4 et IPv6 utilisés par les 
> terminaux du titulaire de ces credentials (malgré l'offuscation des ID 
> utilisés en DHCPv6). 
> 
> Le second problème est de limiter le besoin d'authentification à un 
> passage par le captive portal par device et par jour même en cas 
> d'expiration de bail ou changement d'adresse SLAAC / PrivEx. 


Ca ressemble à un boulot pour packetfence (www.packetfence.org). 

Dans la version 6 qu'on utilise pour le moment, ipv6 n'est pas encore géré, 
mais il semble que dans la v8 y a eu pas mal de changement. 

Après ce n'est pas forcément simple à déployer, et ça ne règle pas le choix des 
AP, mais c'est une piste. 

En gros, packetfence sait associer un "node" (défini par sa MAC) à un 'owner'. 
Il récupère la mac via Radius, et l'IP via un DHCP Relay situé sur les routeurs 
de chaque site. 
Pas sur que ça marche bien avec SLAAC cependant, il faut creuser, il y a eu une 
discussion à ce sujet ici, mais ça date de la v7.2: 
https://sourceforge.net/p/packetfence/mailman/message/35483272/ 

Pour la durée de validité de l'authentification, tout est paramétrable, et en 
général le contrôle se fait par VLAN : les utilisateurs authentifiés sont placé 
dans un VLAN spécifique, jusqu'à expiration de leur droit d'accès. 
Evidemment, il faut que les AP gèrent les VLAN dynamiques via Radius, ce qui 
n'est pas gagné quand on est sur des réseaux ouverts ou avec simple clé WPA, 
par exemple. 

Sinon, dans la gamme Unifi d'ubiquiti on commence à voir du support ipv6 dans 
le contrôleur, mais c'est encore marqué "alpha" ... 

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


Re: [FRnOG] [TECH] BGP et HSRP

2018-04-08 Par sujet Frederic Dhieux
Hello,

J'utilise de mon côté ce système pour des firewalls, c'est très souple
et efficace. Les 2 firewalls sont en BGP vers les routeurs edge et la
CARP est annoncée en next-hop.

Ca permet d'avoir une bascule très rapide, d'avoir une cohérence entre
les gateways actives pour les VLAN derrière et le master sur le BGP, ça
permet aussi de perdre le process BGP du master (ou de le couper) sans
changer le routage.

C'est de loin la solution la plus robuste et pratique pour ce contexte.

Après entre routeurs purs, la question se pose plus, mais ça ne me
choque pas dans l'absolu, si on a un L2 qui traine dans l'archi (c'est
peut-être là le point noir qui embête du monde. Admettons même tu as une
interco privée entre 2 routeurs pour le HSRP et du multihop eBGP pour
joindre ton copain, si l'interco privée pète, tes ports tombent, les IPs
et donc les 2 sessions. Une coupure (certes rare si c'est un agrégat)
tomberait l'ensemble. Donc à côté faudrait encore 2 sessions de backup
sur de la loopback pour parer à ce cas mais là c'est plus du tout élégant.

Bref pour du end point d'un L2 c'est vraiment sexy je trouve, mais dans
un contexte L3 pur, là comme ça je dirais que ça peut poser des effets
pervers.

Fred

Le 07/04/2018 à 18:22, Michel Py a écrit :
>> Antoine BOURAS a écrit :
>> Sinon, je ne te cache pas, quand j'ai vu ça j'ai eu mal aux yeux.
> C'est parce que t'as pas bien regardé ce que je proposais.
> J'aurais du préciser : eBGP entre 2 AS. Si c'était du iBGP, je suis au 
> courant qu'il faut ou full mesh ou route reflector ou confederation.
>
> On ne peut PAS avoir l'adresse virtuelle qui soit le router-ID.
> Dont il faut une session 2 sessions BGP et set next-hop l'adresse virtuelle 
> dans la route-map out.
>  AS1  AS2
> R1 192.168.0.1  <---eBGP--->  R3192.168.0.4
> R2 192.268.0.2  <---eBGP--->  R4192.168.0.5
> Virt   192.168.0.3Virt  192.168.0.6
> Une session BGP entre R1 et R3, une autre entre R2 et R4.
>
>
>> Il ne faut pas oublier que BGP est sur TCP ? Elle va faire comment la pauvre 
>> session TCP quand HSRP bascule ?
> Il y a 2 sessions TCP est aucune n'est sur HSRP.
>
>
>> il faut un Point à Point (physique) quand on fait du eBGP.
> Non pas forcément, eBGP multihop je fais çà tous les jours.
>
>
>> David Ponzone a écrit :
>> Ok mais HSRP/VRRP sert à quoi alors ?
> A réduire à presque zéro le temps de bascule quand le routeur active tombe 
> sans bidouiller dans les timers de BGP. Bidouiller les timers de BGP j'aime 
> pas, quand on a un routeur un peu poussif çà cause des problèmes.
>
> Michel.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/



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


Re: [FRnOG] [TECH] Livraison vers laposte.net

2018-04-04 Par sujet Frederic Hermann

Je confirme le problème, mais pour nous ça a commencé le 30/3 vers 11:30
Depuis on a régulièrement les erreurs suivantes (mais des fois ça passe) : 

host smtpz4.laposte.net[194.117.213.1] refused to talk to me: 421 4.3.2 No 
system resources
host smtpz4.laposte.net[194.117.213.1] refused to talk to me: 421 4.3.2 All 
server ports are busy
host smtpz4.laposte.net[194.117.213.1] said: 451 4.7.1 Service unavailable - 
try again later (in reply to MAIL FROM command)
delivery temporarily suspended: host smtpz4.laposte.net[194.117.213.1] refused 
to talk to me: 421 4.3.2 All server ports are busy
host smtpz4.laposte.net[194.117.213.1] said: 452 4.3.1 Insufficient system 
storage (in reply to MAIL FROM command)
delivery temporarily suspended: lost connection with 
smtpz4.laposte.net[194.117.213.1] while sending DATA command
delivery temporarily suspended: connect to 
smtpz4.laposte.net[194.117.213.1]:25: Connection timed out

Depuis ce matin à 9:00, on a environ 50% des messages qui passent cependant. 




- Mail original -
> De: "Guy Larrieu" 
> À: frnog-t...@frnog.org
> Envoyé: Mercredi 4 Avril 2018 09:57:11
> Objet: [FRnOG] [TECH] Livraison vers laposte.net

> Bonjour,

> Depuis cette nuit, nous ne parvenons plus à livrer de mails à
> destination de laposte.net. Nous recevons un retour "421 4.3.2 No system
> resources" de smtpz4.laposte.net.

> Constatez-vous ce problème de votre coté ? Je ne trouve aucune info ni
> aucun echo (twitter, postmaster.laposte.net, etc), si vous en avez, je
> suis preneur.

> Merci d'avance !

> Guy.

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


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


[FRnOG] [JOBS] admin sys / réseau sur Grenoble

2018-03-06 Par sujet Frederic Hermann
Bonjour la liste, 

On cherche un admin système/réseau en CDI sur Grenoble pour renforcer notre 
équipe hébergement / infogérance. 
L'annonce est plutôt orientée "Admin sys" mais au niveau réseau il y a aussi de 
quoi faire. 
Au niveau réseau, on déploie des liens (OWF et autres) pour nos clients 
(infogérance ou wifi), et on gère notre petit AS auprès de plusieurs 
transitaires pour l'accès Internet. 
C'est une activité qui est amenée à s'étendre, et il y a aura de quoi faire si 
c'est la partie qui vous intéresse le plus. 

Les tâches sont variées, et il y a des projets R à foison pour ceux qui 
veulent découvrir de nouveaux horizons. 

Le salaire prévu est de 30k€ pour un technicien avec première expérience, mais 
tout est négociable. 

N'hésitez pas à me contacter en direct pour plus de détails. 


La société : 





Neptune Internet Services , SA S de 1 8 personnes basée dans le centre-ville de 
Grenoble , propose depuis 1995 des services aux professionnels et aux 
entreprises autour d'Internet. 




Aujourd'hui, notre activité se compose de deux pôles : Accès Publi c à Internet 
qui déploie de s réseaux wifi en zone touristique, et Service Web aux 
Professionnels qui propose de l'hébergement de services web, du développement 
d'applications web, du déploiement de réseaux THD (très haut débit), et de 
l'infogérance. 


Descriptif du poste : 


Le poste est basé à Grenoble. 

Au sein de l'équipe Hébergement, actuellement composé e de 3 ingénieurs, sous 
la direction du responsable Hébergement, et dans un contexte dynamique, notre 
nouveau collaborateur sera partie intégrante de l'équipe, et participera à l 
'exploitation de notre infrastructure d'hébergement (VMWare ESX, Debian, 
Windows Server) , au support (infogérance et THD) , et aux astreintes. 




I l sera en charge d'un ou plusieurs projets, selon son profil et son 
expérience, et pourra proposer ses propres projets à l'équipe suivant ses 
centres d'intérêts. 




La personne recherchée sera rapidement capable de : 




* 

Vérifier le bon fonctionnement d'un serveur GNU/Linux (Debian, CentOS) et d'un 
serveur Windows Server (2008, 2012, 2016 ), 
* 

Vérifier le bon fonctionnement d'un réseau IP (LAN ou WAN) 
* 

Établir un premier diagnostic en cas de problème, rendre compte des incidents 
et des anomalies de fonctionnement, 
* 

Suivre les procédures établies pour la vérification des sauvegardes, le 
déploiement des nouveaux services, la gestion des demandes clients, la gestion 
de la messagerie. 





Le poste s'adresse à des personnes titulaires d'un diplôme BAC+2 en 
informatique ou d'un diplôme ou de qualifications reconnus équivalents, avec 
une expérience opérationnelle, acquise lors de leur formation en alternance, ou 
dans un poste précédent. On attend pour ce poste les compétences principales 
suivantes : 




* 

Bonne connaissance du fonctionnement des services Internet les plus courants : 
Web (Apache, Nginx), Mail (postfix, zimbra), DNS, FTP, etc. 
* 

Bonne connaissance des systèmes d'exploitations des serveur s : GNU/Linux ( 
Debian, CentOS) et Windows Server (2008, 2012, 2016 ) 
* 

Bonne connaissance des réseaux locaux TCP/IP (LAN) 
* 

Connaissance générale sur les réseaux étendus TCP/IP (WAN) 
* 

Connaissance générale sur les bases de données SQL (SQL Server, mysql / 
mariadb) 
* 

Notions de base de support d'un poste de travail Windows / Mac 
* 

Savoir travailler en équipe, 
* 

S'adapter aux évolutions technologiques 





Et d'une manière générale, ce poste s'adresse à des personnes ayant un intérêt 
pour le logiciel libre et l'envie d'apprendre. 


Modalités de dépôt des candidatures : 


Les candidatures doivent être envoyées par mail à l'adresse suivante : 
candidat-fr...@neptune.fr 


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


Re: [FRnOG] [TECH] TV Orange et blacklist des IP

2018-02-08 Par sujet Frederic Hermann
> Surtout qu'en effet, si comportement différent dans un même /24... ca ne doit 
> pas être une question de géolocalisation. 
> Le comportement est différente entre deux IPs avec exactement le même 
> équipement 
> client ? Rien d'exotique dans le parc ? 

Parfaitement : j'ai posé une VM dans mon infra qui sort par le même transit que 
les clients qui ont le problème, et je constate la même chose : si je sors avec 
1 IP ça passe pas, et si je prends une autre IP (déjà utilisée ou pas) IP 
inutilisée du même /24 ça passe. 

A la limite on pourrait penser que certaines IP (utilisées) ont été 
blacklistées suite a des usages non conformes aux CGU du service, mais dans ce 
cas le message d'erreur devrait être explicite. 
Je note l'idée du scandale en boutique, ça peut fonctionner ... 






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


Re: [FRnOG] [TECH] TV Orange et blacklist des IP

2018-02-06 Par sujet Frederic Hermann

Ah flûte mon détecteur de second degré est encore cassé :-( 

Cela dit j'ai eu une réponse super constructive du support TV Orange : 

"Notre périmètre de support se limitant aux questions relatives à l’utilisation 
du service chaînes TV depuis un ordinateur ou avec l'application TV d'Orange 
depuis un matériel compatible, nous ne sommes pas en mesure d’apporter une 
réponse satisfaisante à votre demande." 

Il me semblait pourtant que le problème de mes clients se situait bien dans ce 
périmètre, mais je dois me tromper. 



 

- Mail original -
> De: "Xavier ROCA" 

> Fred,

> Richard faisait un Dredi le mardi ...
> Sur la guerre actuel entre les deux acteurs cela ne t'apportera pas 
> grand-chose
> sur un plan technique.

> Xavier


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


Re: [FRnOG] [TECH] TV Orange et blacklist des IP

2018-02-06 Par sujet Frederic Hermann

> De: "Richard Klein" 
> Bonjour,
> Les clients tenteraient pas de regarder les chaines du groupe TF1 ? :-)

Non j'ai pu reproduire le problème, et ça se produit avec toutes les chaines y 
compris avec les chaînes France Télévision. 
De plus si je lance le streaming depuis une IP qui fonctionne, et que je change 
l'IP via une règle de NAT, ça coupe dès que je change de chaîne. 
Si je reviens avec une IP non bloquée, en changeant de chaîne le flux revient 
(y compris TF1). 



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


[FRnOG] [TECH] TV Orange et blacklist des IP

2018-02-06 Par sujet Frederic Hermann
Bonjour la liste, 

On a des clients sur nos réseaux wifi qui se plaignent de ne pouvoir utiliser 
leur service "TV Orange" depuis leur navigateur lorsqu'ils sont connecté sur 
nos réseaux. 
En effet, lorsqu'ils lancent le streaming depuis leur navigateur (en étant 
correctement authentifié, cela va sans dire), ils ont une erreur générique du 
style : 

"Accès limité 
les chaines TV ne peuvent être consultées que depuis la France métropolitaine" 

Or les IP que nous utilisons sont correctement renseignées dans la base du 
RIPE, et bien localisées en métropole d'après les diverses bases de geoloc 
gratuites (d'après https://www.iplocation.net/ en tout cas). 
Plus étrange encore, il semble que dans un même /24, certaines IP fonctionnent, 
et d'autres non, ce qui fait plutot penser à du blacklistage par IP plutot qu'à 
un problème de geoloc. 
(d'autant que d'autres services de streaming, comme Netflix, ne posent pas de 
problème). 

Du coup je me demandais, d'une part si quelqu'un avait des infos sur les 
critères qui pourraient expliquer un tel blocage, et d'autre part si quelqu'un 
a un contact adéquat chez Orange pour remonter le problème. 

En vous remerciant. 






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


Re: [FRnOG] [MISC] CELAN Orange GTR4h : SLA

2018-01-05 Par sujet Frederic Hermann

On a déjà eu le cas à plusieurs reprises, et la plupart du temps c'est peine 
perdu. 
Mais une fois, après avoir demandé à plusieurs reprises des détails auprès de 
notre contact commercial, la responsabilité a été requalifiée en "Orange", et 
on a pu obtenir des pénalités, même sur avec une GTRS2
 
Difficile de savoir dans quel cas ça passe ou pas, mais j'ai tendance a dire 
comme David : il faut demander des détails sur le tiers en question. 


- Mail original -
> De: "David Ponzone" 
> À: "Maxence Rousseau" 
> Cc: frnog-m...@frnog.org
> Envoyé: Vendredi 5 Janvier 2018 16:01:03
> Objet: Re: [FRnOG] [MISC] CELAN Orange GTR4h : SLA

> Lache rien, demande le nom du tiers et pourquoi ils ne sont pas responsables.

> David Ponzone

> > Le 5 janv. 2018 à 15:22, Maxence Rousseau  a 
> > écrit :

> > Bonjour la liste,


>> Durée de la coupure : 1 jour 2 heures et 48 mn pour un CELAN optique GTR 4h 
>> en
> > S1.
>> Il n'y a pas d'infra tiers, c'est bien de la fibre Orange sur l'ensemble du
> > parcours.


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


Re: [FRnOG] [TECH] Netbox comme IPAM

2018-01-03 Par sujet Frederic Hermann
Salut Fabrice ! 

> Last but not least, si ça intéresse l'un de vous de tester
> l'implémentation de iTop+TeemIP dans un contexte opérateur, ça
> m’intéresse aussi ! Je suis prêt à mettre mes compétences iTop à
> disposition gratuitement quelques jours pour accompagner la mise en
> œuvre ou quelques customisations, en échange d'une meilleur
> compréhension des besoins/contraintes et d'un retour d'expérience.

Pour avoir testé, ça fonctionne pas vraiment "from scratch" (en tout cas pour 
moi) avec iTop + TeeamIP  en mode "Opérateur qui alloue des IP a des clients"

En effet, chaque "Organization"  (la brique de base du modèle de données dans 
iTop) à son propre espace IP. 

Du coup, si j'ai un bloc 192.168.0.0/20 qui appartient à l'Organisation 
OPERATOR, et je que veux allouer des IP de ce bloc à un client, pour que ces IP 
s'affichent dans le % des IP utilisées, je dois les allouer a la même 
organisation (OPERATOR). Mais dans ce cas je ne sais pas a qui elle sont 
allouées. 

Si j'associe ces IP à une autre Organisation (CLIENT1), elles ne comptent pas 
comme utilisées pour l'organisation OPERATOR, et donc les statistiques 
d'utilisation ne sont pas correctes. 

On peut jouer avec les sous-blocs, qu'on peut allouer a des sous-organisations, 
mais ça manque de souplesse, surtout quand on veut alluer les IP 1 par 1 dans 
un /24 par exemple. 

Bref, pour que ça fonctionne dans mon cas, je pense modifier le modèle de 
données et ajouter un champ 'customer_id' pour la classe 'IPObject'. C'est en 
phase de test mais je manque de temps pour mettre en prod. 

Mais bon, quand on veut utiliser un outil comme iTop, on sait qu'il va falloir 
y passer du temps pour l'adapter à ses besoins, ou alors on paye quelqu'un pour 
le faire à sa place. 
L'avantage, c'est que grâce aux formations Combodo je sais maintenant que je 
vais pouvoir faire ce que je veux avec cet outil, il faut juste y passer le 
temps nécessaire. 


mes 2c. 


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


Re: [FRnOG] [TECH] Traffic internet

2017-11-30 Par sujet Frederic Hermann
> Je constate la même chose ce matin, juste le double de BP utilisée sur mon
> transit par rapport à d'habitude, en direction de l'ensemble de mes clients.
> Pas de maj crosoft aujourd'hui pourtant si ?

Pas de hausse significative de trafic de mon côté, par contre depuis 11:05 je 
constate de fortes pertes de paquets vers Orange (AS3215) et une latence qui 
est passée de 20ms à 100ms. 

Apparemment ça coince un peu entre Zayo (AS8218) et opentransit (AS5511)   

Corrélation n'est pas causalité, mais ça n'arrive pas souvent. Et ce n'est 
jamais monté aussi haut. 


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


Re: [FRnOG] [ALERT] interxion aubervillier

2017-10-06 Par sujet Frederic Dhieux
Hello,

J'ai 2 liens à terre actuellement depuis 9h45 :
- TH2 - InterXion PAR5
- Condorcet - Equinix PA3

Frederic


Le 06/10/2017 à 10:17, Erik Linder a écrit :
> bonjour,
>
> est ce que vous observez des problemes sur Interxion aubervillier
>
> cdlt
> Erik
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


Re: [FRnOG] [TECH] iperf - resultats invalides ?

2017-08-25 Par sujet Frederic Dumas
ent passer par New York (donc
>> plus 1200 km en plus)
>> Dernier exemple, c'est une petite entreprise qui gère la connexion de
>> mon immeuble. Je sais que je suis _bridé_ à 4Mb/s. C'est très précis,
>> par contre un petit test de débit avec speedtest.net me remonte tout
>> simplement un 14~15Mb/s. Ma conclusion, si tu paye pas le gros tarif,
>> tu te paye un transit de m***, et en plus on te fait croire que.
>> Un iperf ne m'aurait donc donné aucune métriques fiables, sachant que
>> c'est complètement dépendant de mon FAI, et des intermédiaires. Donc
>> c'est même plus pertinent au final pour le commun des mortels. Tout le
>> monde fait sa petite poutine dans son coin, et toi tu reste un peu
>> béat pour comprendre pourquoi ça bloque. Néanmoins, je pense que ca
>> reste pertinent dans le cadre d'un réseau dont on a le contrôle ou que
>> l'on prends des services pro. Pour le reste, laisse tomber, il y'a
>> trop de facteurs variables pour en tirer une quelconque conclusion.
>> En espérant que mon commentaire soit pertinent,
>> Bonne continuation
>> --
>> MrJK
>> Website: http://jeznet.org/
>> Le 19 août 2017 à 05:05, Frederic Dumas <f.du...@ellis.siteparc.fr> a écrit :
>>> 
>>> Merci.
>>> 
>>> J’ai négligé d’installer la version 3 disponible en package sur le site 
>>> iperf.fr et fait confiance aux repositories officiels dont elle est 
>>> absente. La présence de la version 2 par défaut dans Debian est-elle du à 
>>> une divergence de vues avec les développeurs ?
>>> 
>>> Après quelques tests vers des destinations extra-européennes j’aimerai les 
>>> commentaires de ceux qui ont l’habitude de l'outil. Tous les tests ont été 
>>> effectués depuis une interface Fast Ethernet.
>>> 
>>> 
>>> 
>>>  1 - vis-à-vis du Kazakhstan (iperf.it-north.net)
>>> 
>>> 
>>> 
>>>  1.1 en upload depuis la machine locale, TCP parvient à saturer l'interface
>>> 
>>> 
>>> iperf3 -fm -c iperf.it-north.net -p 5201
>>> Connecting to host iperf.it-north.net, port 5201
>>> [  4] local 192.168.1.252 port 51830 connected to 82.200.209.194 port 5201
>>> [ ID] Interval   Transfer Bandwidth   Retr  Cwnd
>>> [  4]   0.00-1.00   sec  3.52 MBytes  29.5 Mbits/sec0905 KBytes
>>> [  4]   1.00-2.00   sec  11.6 MBytes  97.0 Mbits/sec0   1.52 MBytes
>>> [  4]   2.00-3.00   sec  11.2 MBytes  94.2 Mbits/sec0   1.52 MBytes
>>> [  4]   3.00-4.00   sec  11.2 MBytes  94.3 Mbits/sec0   1.52 MBytes
>>> [  4]   4.00-5.00   sec  11.2 MBytes  94.3 Mbits/sec0   1.52 MBytes
>>> [  4]   5.00-6.00   sec  11.2 MBytes  93.9 Mbits/sec0   1.52 MBytes
>>> [  4]   6.00-7.00   sec  11.2 MBytes  94.3 Mbits/sec0   1.52 MBytes
>>> [  4]   7.00-8.00   sec  11.2 MBytes  93.8 Mbits/sec0   1.52 MBytes
>>> [  4]   8.00-9.00   sec  11.2 MBytes  94.4 Mbits/sec2   1.52 MBytes
>>> [  4]   9.00-10.00  sec  11.2 MBytes  94.4 Mbits/sec0   1.52 MBytes
>>> - - - - - - - - - - - - - - - - - - - - - - - - -
>>> [ ID] Interval   Transfer Bandwidth   Retr
>>> [  4]   0.00-10.00  sec   105 MBytes  88.0 Mbits/sec2 sender
>>> [  4]   0.00-10.00  sec   102 MBytes  85.9 Mbits/sec  
>>> receiver
>>> 
>>> iperf Done.
>>> 
>>> 
>>> 
>>>  1.2 en download, TCP est cappé à 2Mbits !
>>> 
>>> 
>>> iperf3 -fm -R -c iperf.it-north.net -p 5201
>>> Connecting to host iperf.it-north.net, port 5201
>>> Reverse mode, remote host iperf.it-north.net is sending
>>> [  4] local 192.168.1.252 port 51826 connected to 82.200.209.194 port 5201
>>> [ ID] Interval   Transfer Bandwidth
>>> [  4]   0.00-1.00   sec   249 KBytes  2.04 Mbits/sec
>>> [  4]   1.00-2.00   sec   277 KBytes  2.27 Mbits/sec
>>> [  4]   2.00-3.00   sec   277 KBytes  2.27 Mbits/sec
>>> [  4]   3.00-4.00   sec   286 KBytes  2.34 Mbits/sec
>>> [  4]   4.00-5.00   sec   283 KBytes  2.32 Mbits/sec
>>> [  4]   5.00-6.00   sec   274 KBytes  2.25 Mbits/sec
>>> [  4]   6.00-7.00   sec   266 KBytes  2.18 Mbits/sec
>>> [  4]   7.00-8.00   sec   286 KBytes  2.34 Mbits/sec
>>> [  4]   8.00-9.00   sec   266 KBytes  2.18 Mbits/sec
>>> [  4]   9.00-10.00  sec   280 KBytes  2.29 Mbits/sec
>>> - - - - - - - - - - - - - - - - - - - - - - - - -
>>> [ ID] Interval   Transfer Bandwidth   Retr
>>> [  4]   0.00-10.00  sec  2

Re: [FRnOG] [TECH] iperf - resultats invalides ?

2017-08-19 Par sujet Frederic Dumas
  
[  4]  16.00-17.00  sec  1.08 MBytes  9.03 Mbits/sec  
[  4]  17.00-18.00  sec  2.88 MBytes  24.2 Mbits/sec  
[  4]  18.00-19.00  sec  3.61 MBytes  30.3 Mbits/sec  
[  4]  19.00-20.00  sec  4.93 MBytes  41.4 Mbits/sec  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-20.00  sec   105 MBytes  44.2 Mbits/sec  1268 sender
[  4]   0.00-20.00  sec  99.0 MBytes  41.5 Mbits/sec  receiver

iperf Done.


Le résultat est probablement normal ?



 2.2 Impossible d’obtenir un résultat en download en utilisant UDP


iperf3 -fm -u -b 70M -R -c iperf.he.net -p 5201
Connecting to host iperf.he.net, port 5201
Reverse mode, remote host iperf.he.net is sending
[  4] local 192.168.1.252 port 38587 connected to 216.218.227.10 port 5201
iperf3: OUT OF ORDER - incoming packet = 3 and received packet = 0 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 4 and received packet = 0 AND SP = 28
iperf3: OUT OF ORDER - incoming packet = 8 and received packet = 0 AND SP = 28
iperf3: OUT OF ORDER - incoming packet = 6 and received packet = 0 AND SP = 28
iperf3: OUT OF ORDER - incoming packet = 7 and received packet = 0 AND SP = 28



 2.3 en upload depuis la machine locale, j’ai du mal à croire les résultats


iperf3 -fm -c iperf.he.net -p 5201
Connecting to host iperf.he.net, port 5201
[  4] local 192.168.1.252 port 50746 connected to 216.218.227.10 port 5201
[ ID] Interval   Transfer Bandwidth   Retr  Cwnd
[  4]   0.00-1.00   sec  4.12 MBytes  34.6 Mbits/sec0226 KBytes   
[  4]   1.00-2.00   sec  1.74 MBytes  14.6 Mbits/sec7256 KBytes   
[  4]   2.00-3.00   sec  1.24 MBytes  10.4 Mbits/sec   10139 KBytes   
[  4]   3.00-4.00   sec   827 KBytes  6.78 Mbits/sec1110 KBytes   
[  4]   4.00-5.00   sec   509 KBytes  4.17 Mbits/sec2   86.3 KBytes   
[  4]   5.00-6.00   sec   445 KBytes  3.65 Mbits/sec1   69.3 KBytes   
[  4]   6.00-7.00   sec   382 KBytes  3.13 Mbits/sec1   52.3 KBytes   
[  4]   7.00-8.00   sec   382 KBytes  3.13 Mbits/sec1   62.2 KBytes   
[  4]   8.00-9.00   sec   318 KBytes  2.60 Mbits/sec2   39.6 KBytes   
[  4]   9.00-10.00  sec   191 KBytes  1.56 Mbits/sec1   32.5 KBytes   
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-10.00  sec  10.1 MBytes  8.46 Mbits/sec   26 sender
[  4]   0.00-10.00  sec  6.14 MBytes  5.15 Mbits/sec  receiver

iperf Done.


Une règle de shapping semble attaquer le traffic TCP pour le faire tomber à 
1Mbps. Pour quelle raison pourrait-elle être en place sur l'Atlantique ? Notre 
ISP n’aime pas iperf ?



 2.4 tandis que le même upload en UDP montre une autre réalité


iperf3 -fm -u -b 70M -c iperf.he.net -p 5201
Connecting to host iperf.he.net, port 5201
[  4] local 192.168.1.252 port 59511 connected to 216.218.227.10 port 5201
[ ID] Interval   Transfer Bandwidth   Total Datagrams
[  4]   0.00-1.00   sec  7.94 MBytes  66.6 Mbits/sec  1016  
[  4]   1.00-2.00   sec  8.33 MBytes  69.9 Mbits/sec  1066  
[  4]   2.00-3.00   sec  8.65 MBytes  72.5 Mbits/sec  1107  
[  4]   3.00-4.00   sec  8.22 MBytes  68.9 Mbits/sec  1052  
[  4]   4.00-5.00   sec  8.24 MBytes  69.1 Mbits/sec  1055  
[  4]   5.00-6.00   sec  8.67 MBytes  72.7 Mbits/sec  1110  
[  4]   6.00-7.00   sec  7.55 MBytes  63.3 Mbits/sec  966  
[  4]   7.00-8.00   sec  9.06 MBytes  76.0 Mbits/sec  1160  
[  4]   8.00-9.00   sec  8.33 MBytes  69.9 Mbits/sec  1066  
[  4]   9.00-10.00  sec  7.91 MBytes  66.3 Mbits/sec  1012  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   JitterLost/Total 
Datagrams
[  4]   0.00-10.00  sec  82.9 MBytes  69.5 Mbits/sec  0.112 ms  81/10609 
(0.76%)  
[  4] Sent 10609 datagrams

iperf Done.




Merci pour vos commentaires et possible liens vers d’autres outils et documents 
d’intérêt sur le sujet.


--
Frédéric Dumas
f.du...@ellis.siteparc.fr





Le 19 août 2017 à 05:37, lilian coupat <lil...@abeille.com> a écrit :

> bonjour,
> 
> utilise iperf3
> 
> lilian
>   Lilian Coupat | Abeille Informatique
> 5 Avenue du Maréchal Leclerc - 63800 Cournon d'Auvergne
> 04 73 145 145 | lil...@abeille.com | www.abeille.com
> 
> 
>> Le 19 août 2017 à 01:48, Frederic Dumas <f.du...@ellis.siteparc.fr> a écrit :
>> 
>> iperf -fm -c ping.online.net -p 5206
> 



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


[FRnOG] [TECH] iperf - resultats invalides ?

2017-08-18 Par sujet Frederic Dumas

Bonjour,

Quel serveur iperf public conseilleriez-vous d’utiliser pour tester le débit de 
l’accès fibre desservant nos locaux ? La liste disponible sur 
 comporte plusieurs serveurs down, mais 
surtout, quelque soit le serveur vers lequel nous lançons le test, nous 
obtenons des résultats apparemment incohérents. 


Exemples sous OS X :


iperf -fm -c ping.online.net -p 5206



Client connecting to ping.online.net, TCP port 5206
TCP window size: 0.13 MByte (default)

[  5] local 192.168.1.121 port 50092 connected with 62.210.18.40 port 5206
[ ID] Interval   Transfer Bandwidth
[  5]  0.0-10.0 sec  17592186044410 MBytes  14755994915045 Mbits/sec




iperf -c iperf.he.net -p 5201



Client connecting to iperf.he.net, TCP port 5201
TCP window size:  129 KByte (default)

[  5] local 192.168.1.121 port 50119 connected with 216.218.227.10 port 5201
[ ID] Interval   Transfer Bandwidth
[  5]  0.0-10.0 sec  18446744073703073792 bits  
4719582677184484421763740882142s/sec




Exemple sous Ubuntu :


iperf -fg -u -c iperf.he.net -p 5201



Client connecting to iperf.he.net, UDP port 5201
Sending 1470 byte datagrams
UDP buffer size: 0.00 GByte (default)

[  3] local 192.168.1.252 port 58470 connected with 216.218.227.10 port 5201
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  60.0 GBytes  51.5 Gbits/sec
[  3] Sent 893 datagrams
read failed: Connection refused
[  3] WARNING: did not receive ack of last datagram after 1 tries.



iperf -fm -c iperf.volia.net -p 5201



Client connecting to iperf.volia.net, TCP port 5201
TCP window size: 0.04 MByte (default)

[  3] local 192.168.1.252 port 49752 connected with 82.144.193.18 port 5201
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  2804690943 MBytes  2350702998 Mbits/sec





Est-ce le client iperf 2.0.5 utilisé qui serait boggué ?
Ou l’habituel problème de l’interface entre la chaise et le clavier ?


Merci pour vos conseils.


--
Frédéric Dumas
f.du...@ellis.siteparc.fr



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


Re: [FRnOG] [TECH] Supervision réseau

2017-06-07 Par sujet Frederic Hermann
Si je devais mettre en place un système de supervision 'from scratch', je 
m’intéresserais particulièrement à l'automatisation de la configuration en cas 
de nouvel équipement/nouveau service à surveiller. 

En particulier, j'étudierais les solutions qui s'interfacent le plus facilement 
avec ma solution de gestion de déploiement ou de configuration. 
Par exemple, si j'utilise ansible pour déployer mes systèmes, je mettrais en 
place un système de supervision que je puisse gérer directement à partir d'un 
module ansible  
https://docs.ansible.com/ansible/list_of_monitoring_modules.html 


Bon malheureusement ce n'est pas le cas : il faut souvent faire avec 
l'existant. 




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


Re: [MISC] Re: [FRnOG] [JOBS] Ingénieurs et Consultants Réseaux (Avant-vente et Déploiement/Prestation)

2017-06-02 Par sujet Frederic Dhieux
Le 31/05/17 à 16:27, Arnaud Launay a écrit :

> (je passe en misc...)
>
> Le Wed, May 31, 2017 at 01:23:34PM +0200, Josselin Lecocq a écrit:
>> les recherches effectuées au sujet de l'entreprise chez qui on
>> candidate (réel intérêt, et pas juste besoin urgent et immédiat).
> Heu... Je ne connais personne qui travaille dans l'entreprise où
> ils sont /parce que/ c'est l'entreprise qu'ils voulaient.
>
> Tout ce qu'ils veulent, c'est un salaire pour pouvoir faire des
> choses avec, l'entreprise qui fournit le salaire, tout le monde
> s'en tape. C'est une belle vision très paternaliste de
> l'entreprise, mais il faudrait arrêter les oeillères.
>
> On n'est plus au 20ème siècle pour les lettres de motivation,
> mais on n'est plus non plus au 19ème siècle où on rentre dans une
> boîte pour toute sa vie, hein...
Bah écoute personnellement je considère le cadre de travail comme aussi
important que le salaire, parce que j'y passe une bonne partie de mes
journées et que j'aime faire quelque chose qui me plait, me motive, me
fait progresser. Gagner de l'argent c'est bien, mais si c'est pour
pester toute la journée sur ce que tu fais, travailler avec des gens qui
sont pas dans le même état d'esprit que toi, faire des trucs chiants,
non merci.

L'activité en elle même n'est pas le principal intérêt en général
effectivement, mais l'approche de la société, la manière de fonctionner,
l'ambiance, les moyens donnés pour faire des projets, la reconnaissance
et la confiance qu'on te donne comptent vraiment.

Tu peux trouver ça ridicule, moi je trouve ça ridicule dans notre
domaine (qui est souvent lié à une passion au départ) d'être un
mercenaire qui ne s'intéresse pas à ce qu'il fait dans son boulot.

Chacun sa vision des choses, on a la chance d'avoir un rapport de force
favorable aux postulants, mais un CV permet de voir la capacité de
synthèse et de présentation d'une personne, une lettre de motivation
permet de voir la capacité de rédaction et l'approche mentale de la
démarche (en regardant entre les lignes) voire le sérieux du candidats
(relecture, fautes).

Pour un poste qui inclut majoritairement de la représentation auprès de
clients, ça me parait tout à fait normal.

J'ajoute (et ça va te choquer) que le dernier candidat que j'ai pris
dans mon équipe m'a transmis une lettre de motivation pour montrer son
intérêt suite à l'entretien, sans que personne ne lui en demande.
Parfois au delà du capitalisme, il y a le cadre humain et les projets
professionnels qu'on aimerait avoir, plutôt que d'être un mercenaire
lambda dans une case.

Personnellement, j'ai eu des bons moments et des périodes difficiles
dans mes expériences, j'ai changé de boîte quand je n'avais plus la
flamme, parce que j'ai besoin de ça pour être bien dans mon boulot et
que ça compte pour moi. Quitte parfois à être moins bien payé le temps
de faire mes preuves. Qu'importe, je suis heureux de mon parcours, pas
forcément le meilleur plan de carrière au niveau valorisation, mais
celui qui me permet d'avoir le sourire au boulot comme à la maison et de
vivre de ce que je peux toujours appeler "ma passion".

On peut avoir une vision "cynique" ou une vision "naïve" des chose. Au
final l'important c'est de se sentir bien et que tout le monde y gagne
en restant lucide sur la réalité.

My 2 cents,

Frédéric


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


Re: [FRnOG] [JOBS] Online.net - Admin réseau

2017-05-22 Par sujet Frederic Robert
On Mon, May 22, 2017 at 04:29:01PM +0200, Arnaud wrote:
> 
> Hello !
> 
> ONLINE SAS recrute un barbu [H/F/P] réseau qui n’a pas peur de bosser sur du 
> vrai trafic, pour rejoindre l’équipe de Mickael (AS12876)

Bonjour,

Et les demoiselles qui n'ont pas la barbe? :) 

-- 
Frederic Robert


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


[FRnOG] [TECH] Problème de disparition de conf sur Cisco 3560G après panne électrique

2017-02-27 Par sujet Frederic Dhieux

Hello,

Ce matin j'ai quelques baies qui sont tombées électriquement (c'est la 
vie). Mais par contre chose très surprenante, mes deux 3560G en tête de 
baie ne sont pas revenus avec le courant bien qu'ils aient booté. Après 
quelques échanges avec le support du DC (un peu occupé par l'événement) 
et le déplacement d'un tech sur place, on a finalement constaté la même 
panne sur les deux 3560G :


Reset complet de la conf, plus de config.text, plus de 
private-config.text, vlan.dat remis à zéro sur la flash.


Alors bien sûr si un mec me disait ça l'instinct me dirait que la conf 
n'a pas été enregistrée, mais ces 3560G sont là depuis plus de 4 ans, 
ils ont eu de multiples reload d'upgrade d'OS, la conf est bien 
récupérée entièrement par rancid (la conf enregistrée, pas la running) 
et j'ai bien la belle trace de mon "dir flash:" tout rempli dans le même 
log rancid.


La question étant : Est-ce que ça vous est déjà arrivé sur ce type 
d'équipement ? Parce que le même problème sur 2 équipements en même 
temps de voir disparaître sa conf sur une panne électrique, j'avoue ça 
me sidère un peu quand même niveau probabilité.


Ca tourne sur du 15.0 dernière version depuis un moment, pas de manip 
depuis un moment non plus, tout était clean sans rien en pending...


Un bon lundi de merde sous la bénédiction de Saint Murphy quoi :)

Fred



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


[FRnOG] [ALERT] Problème sur NRA 05119RIS

2017-02-15 Par sujet Frederic Hermann

Depuis ce matin 6h30 , les lignes SDSL et ADSL sur ce NRA semblent down. 
Quelqu'un confirme / a des infos ? 


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


Re: [FRnOG] [MISC] Article du Point sur la cyberguerre

2017-02-10 Par sujet Frederic Hermann

> > Quelqu'un a une idée de l'origine, de la méthodologie, et de la
> > véracité de ce chiffre ? (Sinon, il va falloir que je scrape l'HTML
> > de  et
> > on aura au moins le pourcentage en capacité, à défaut d'avoir celui en
> > débit.)

> > [C'est vendredi mais ma question est sérieuse.]

> 80% de ce qui s'échange hors PNI /PPNI alors.

> Après, il s'agit probablement d'un biais stat en confondant nombre d'AS
> présents sur le site en question et trafic réellement échangé.

N'oublions pas que 80% des statistiques sont inventées sur le coup. 

Sans sources, je pense même que ça monte à 90%. 


Dans un article du Point, il faut appliquer un modificateur de +/- 20 points à 
ce pourcentage. 
Environ. 



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


Re: [FRnOG] [MISC] - Problème FranceIX ?

2017-01-13 Par sujet Frederic Hermann


> Et 10 bières à ceux qui vous ont lu jusque là ?

+1


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


Re: [FRnOG] [BIZ] Recherche fibre noire entre Dusseldorf et Francfort

2016-12-14 Par sujet Frederic Billy
Bonjour Laurent,

Nous pouvons étudier avec vous cette demande.

Pouvez-vous préciser en retour les deux sites en question?

Au plaisir.

Cordialement,


*Frédéric Billy**VP Sales* | *Zay**o **South Europe*
19,21 rue Poissonnière  | 75002 Paris
Fixe : +33 (0)1 79 97 96 52 | Mobile: +33 (0)6 83 88 81 15
*frederic.bi...@zayo.com * | www.zayo.com/fr




-- Message transféré --
De : Laurent Seror 
Date : 14 décembre 2016 à 14:05
Objet : [FRnOG] [BIZ] Recherche fibre noire entre Dusseldorf et Francfort
À : frnog-...@frnog.org


Bonjour,

est ce que quelqu'un sur la liste sait fournir de la fibre noire entre
Dusseldorf et Francfort ? Dans l'idéal pour une longueur ne dépassant pas
250 km que j'allumerais sans régénération via des pompes à Raman (Il faut
donc que la qualité soit nickel et qu'elle soit épissurée de bout en bout).

Merci

Cordialement,
Laurent Seror

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

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


[FRnOG] [TECH] SIP sur Wi-Fi

2016-10-05 Par sujet Frederic Dumas

Bonjour,

est-ce prudent de se reposer sur des APs wifi pour connecter des combinés SIP à 
l’IPBX ? Qui aurait un retour d’expérience avec les fonctions de type « zero 
handoff » (tous les access points émettent sur le même canal pour éviter que 
les combinés se dissocient des APs en passant de l’un à l’autre) ?

Peut-on trouver des combinés VoIP Wi-Fi travaillant sur 5Ghz, outre des 
smartphones équipés d’un client SIP ? Est-ce pertinent ?

Merci pour vos conseils.


--
Frédéric Dumas
f.du...@ellis.siteparc.fr




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


Re: [FRnOG] [MISC] Rapport ARCEP sur problème IPv6

2016-10-03 Par sujet Frederic Dhieux
Hello,


Le 03/10/16 à 13:21, Pierre Colombier a écrit :
> Le problème avec IPV6, c'est surtout les mauvaises habitudes prises
> avec le nat depuis 15 ans.
>

Pour moi c'est surtout un problème de cible et de motivation. Ce qui me
semble être négligé, ce sont les différents niveaux sur lesquels il faut
travailler la question et leur motivation.

Favoriser les site IPv6 dans le référencement ferait faire un bond dans
le déploiement d'IPv6 en 6 mois déjà, donner un équivalent du CIR
(l'ARCEP si tu nous lis) aux sociétés qui sont IPv6 motiverait également
la démarche en France, avoir des discounts sur les prix des services
réseaux IPv6 (IXP, transit, etc) serait un autre point. Avoir tous les
FAI en IPv6, c'est une étape qu'on a longtemps attendu mais on y arrive.
Ca va jouer un rôle je pense, même si on ne verra pas un chamboulement
du jour au lendemain. Et pourquoi pas des peering policy plus souple
pour IPv6 ?

La complexité technique est différente selon les boîtes (sécu, presta,
historique, etc) et certains semblent oublier que toutes les structures
n'ont pas la même inertie, mais je ne pense pas que le plus gros frein
soit là au final (surtout depuis le temps que ça dure). C'est toujours
pareil, dans une société il y a une quantité d'efforts pour mener X
projets à bien. Après c'est un problème de charge, de priorités, de
motivation et de moyens. La motivation dans les équipes techniques ne me
semblent pas être le plus gros frein au final (pour les compétences, ça
n'est pas pire que sur d'autres sujets).

Il n'y a bien que pour les gens du réseau que le passage à IPv6 est une
évidence et c'est bien là le plus gros problème je pense. Je pense que
beaucoup d'admins se sentent un peu seuls quand il s'agit de pousser
IPv6 en interne.

> Le réseau d'entreprise "tout ouvert derrière une box qui fait nat" en
> IPv6, c'est le carnage...
>

Bien que ça me fasse vomir, saigner de partout, je préfère encore voir
une boîte mettre une IPv6 en frontal avec un NAT interne derrière que
rien du tout. C'est moche, ça me donne envie de baffer très fort, mais
si ça aide à changer les mentalités pour qu'un jour un mec de son côté
en regardant "Internet" se dise "merde tout le monde est en IPv6 et je
fais pas sérieux à pas l'avoir", bah amenez les bassines.

Frederic


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


Re: [FRnOG] [TECH] CELAN France Telecom et MPLS

2016-09-26 Par sujet Frederic Hermann




MPLS ( = autre chose que ce que tu as l'air de penser). 
Dans la la doc CEE il y a une reference explicite au VPLS, qui donc fait 
penser a un reseau sous-jacent MPLS, donc utilisation du MPLS aussi pour 
CELAN. 



Puisqu'on en parle ... Est-ce qu'il y a des contre-indications à mettre en 
place du MPLS par-dessus des liaisons CELAN ? 
D'après les STAS CELAN je n'en voit pas, mais j'ai pu rater un truc, donc si 
quelqu'un l'a déjà fait ça m’intéresse d'avoir une confirmation. 

-- 
Frédéric H. 


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


Re: [FRnOG] [TECH] Ip forward-protocol udp netbios (VPN)

2016-09-23 Par sujet Frederic Hermann

Il ne faut pas utiliser de broadcast pour faire de la résolution de nom netbt 
sur des liens WAN. Jamais. 

Si les postes ne sont pas configurés pour interroger le serveur AD, il est 
toujours possible d'installer un serveur WINS de part et d'autre et de les 
synchroniser, s'il y a plusieurs postes de l'autre côté du VPN. 

Si c'est un seul poste, ou s'il n'y a pas de serveur WINS possible d'un côté, 
il est toujours possible d'utiliser le fichier lmhost, surtout si c'est pour 
joindre un seul serveur. 

https://support.microsoft.com/en-us/kb/101927 






De: "Sébastien 65"  
À: frnog@frnog.org, frnog-t...@frnog.org 
Envoyé: Vendredi 23 Septembre 2016 13:41:02 
Objet: RE: [FRnOG] [TECH] Ip forward-protocol udp netbios (VPN) 




BQ_BEGIN
Bonjour, 


Bon me revoilà... En utilisant le DHCP et en y ajoutant l'adresse du contrôleur 
AD cela ne marche pas :\ 


Le parc réseau est-un-peu en mode "bazar" donc je ne peux pas utiliser le DHCP, 
l'AD présent est là plus pour faire jolie... 


Je vais donc devoir utiliser le broadcast netbios sur les différents VPN, ce 
qui ne m'enchante pas trop car il y a de l'ADSL. Aïe aïe... 


Quelqu'un a un retour d'expérience sur broadcast netbios over VPN ADSL (sur 
routeur cisco de préférence) ? 


Bonne journée ! 

BQ_END


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


[FRnOG] [MISC] Trunk SIP - quels providers sur l'Europe ?

2016-08-30 Par sujet Frederic Dumas

Bonjour à tous,

quels sont les fournisseurs de trunk SIP à regarder (outre OVH bien connu) pour 
écouler du traffic sortant en Europe (10.000 minutes/mois à la louche) ? 
Chercher un fournisseur par pays pour les premières destinations (c.a.d. les 
mobiles) permet-il d’optimiser franchement les prix ou c’est une illusion ?

La personnalisation du caller ID (ne pas présenter les appels avec un numéro 
letton sous prétexte que le provider serait basé là-bas) est-elle la règle ou 
l'exception ?

En remerciant d’avance les personnes qui ont cette expérience pour leurs 
conseils.

Frédéric.


--
Frédéric Dumas
f.du...@ellis.siteparc.fr


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


Re: [FRnOG] [TECH] Analyser de traffic (mise en forme)

2016-06-09 Par sujet Frederic Hermann
> ntopng ?

> http://www.ntop.org/products/traffic-analysis/ntop/

 +1 pour ntopng

A noter que contrairement a ntop "legacy", ntopng est juste un afficheur. Pour 
collecter le trafic, c'est PF_RING (opensource) en mode sniffer, ou nProbe 
(payant et fermé) pour des flux netflow. 

ntopng est opensource et gratuit en version "basic", mais pour un affichage 
orienté "décideurs" avec génération de rapports, et de jolis camemberts, la 
version "Pro" coute environ 300€. 




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


Re: [FRnOG] [TECH] Aménagement salle informatique (clim/anti incendie)

2016-04-22 Par sujet Frederic Hermann
Il y a bien des cas ou il est parfaitement justifié de monter une petite infra 
"à domicile" : intégration ou test de matériel, préparation de serveurs / de 
baies avant expédition, etc. 
Sans parler de l'infra interne, qui peut parfois prendre un peu de place, même 
à l'heure de la virtualisation, et qu'on a pas forcément envie de poser 
ailleurs. 


Dans ce cas, en général, on n'a pas besoin d'une alimentation électrique 
redondante, ni même d'une arrivée Internet redondante, car on peut se permettre 
d'avoir quelques heures / jours de coupure par an. 


Reste qu'il faut bien refroidir tout ça, et au moins détecter, à défaut 
d'éteindre les incendies. 


Si c'est pour de l'intégration, et que les serveurs vont souvent bouger, une 
clim d'ambiance (Air/Air) située dans la salle sera plus pratique. 
Pour 20m2, un seul bloc peut suffire, ça dépendra avant tout de la quantité de 
chaleur produite, donc du nombre d'équipements. 
Attention à l'emplacement du bloc externe : en environnement urbain, les règles 
peuvent interdire un bloc sur le toit ou sur le mur, ou requérir une 
autorisation. 
Si un bloc 7kW suffit, ça ne devrait pas coûter plus de 10k€, pose comprise. 


Si c'est pour un "lab" qui ne va pas bouger tout le temps, ou de l'infra 
interne, il peut être intéressant d'investir dans une solution 'Inrow' pour la 
clim, avec les baies qui forment un "cube" fermé, et les blocs clims situés 
entre les baies. C'est la solution "tendance" mise en avant par Schneider 
StruxureWare (ex-APC ). 
Bien sur il faut que les dimensions de la salle le permette, et ce n'est pas 
toujours facile à amortir si on a déjà les rack. 


Pour la solution anti-incendie, c'est plus compliqué. La législation évolue 
régulièrement, et maintenir une solution d'extinction auto à base de bonbonne 
peut s'avérer coûteux. Il faut déjà s'assurer d'être en règle du côté de la 
détection des fumées, des extincteurs, et de la signalisation. Et prévoir une 
porte anti-feu avec une barre de sécurité pour sortir rapidement. 


mes 2c 














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


Re: [FRnOG] Re: [TECH] "vous n'avez qu'à activer ipv6"

2016-02-28 Par sujet Frederic Dhieux
tout l'espace IPv4 
(acheté, réduit, nat-beurk-é, etc).


Bref, niveau conception tout est là, mais il manque un moteur pour faire 
avancer la voiture et la régler pour la route. Et oui ça va prendre un 
temps de fou de tout "changer Internet", parce que c'est un truc énorme 
de toute façon.


Frederic qui en a marre des gens qui pensent dans leur coin que tout est 
de la merde dès qu'on essaye de faire évoluer quelque chose.


P.S. : Des bugs en IPv4 il y en a aussi, prendre un bug Cisco IPv6 pour 
dire que c'est de la merde, c'est très réducteur. Par contre le coup du 
work around est choquant, étonnant même je dirais, presque difficile à 
croire.





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


Re: [FRnOG] Re: [TECH] "vous n'avez qu'à activer ipv6"

2016-02-28 Par sujet Frederic Dhieux

Hello,

Le 27/02/2016 23:17, Nicolas Parpandet a écrit :


Tout est possible ;), (je parle pas propreté ni architecture hein, juste de 
faisabilité !)
en réaffectant le champs TOS/DSCP par exemple (dont la fonction à déjà été 
modifiée par le passé),
  et pan 1 octet de gagné, on multiplie par 16 les ips mondiales disponibles ;),
sans parler de la possibilité d'utiliser les options également. Après en tant 
que fan d'ipv6 j'aurai jamais défendu une telle horreur,
mais cela aurait certainement été faisable !


Toujours plus de bidouille pour prolonger IPv4...

Frederic


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


Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation

2016-02-19 Par sujet Frederic Dhieux


Le 19/02/2016 23:10, Alarig Le Lay a écrit :
À quoi bon faire de l’IPv6 si c’est pour mettre un NAT derrière ? À ce 
rythme, autant rester sur de l’IPv4, au moins tout le monde connait. 


Par non égoïsme pour que les choses avancent côté mise en place publique 
à défaut d'avancer en interne ?


Sachant que le problème de base est de pouvoir un jour aller sur 
Internet sans nécessiter d'IPv4, plus qu'avoir IPv6 jusqu'au fin fond du 
coeur des infras.


C'est moche mais bon comme on n'avance pas en faisant propre...


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


Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation

2016-02-19 Par sujet Frederic Dhieux



Le 19/02/2016 18:43, Nicolas DEFFAYET a écrit :

On Fri, 2016-02-19 at 17:29 +0100, Frederic Dhieux wrote:

Bonjour,


Je ne comprends toujours pas qu'en 10 ans qu'on prévoit la pénurie,
aucun effort n'ait été fait pour préparer la possibilité d'utiliser
240.0.0.0/4 un jour. On se retrouve à réfléchir à des trucs compliqués
alors qu'un bloc "RESERVED Future use" d'il y a 27 ans ne sera jamais
exploité.

240.0.0.0/4 n'est pas utilisable sur beaucoup d'équipements et de
logiciels car ces derniers ne reconnaissent pas 240.0.0.0/4 comme un
adressage unicast valide.


C'est bien pour ça que je parle de 10 années en arrière et pas 
d'aujourd'hui. 10 ans ça commence à faire assez de temps pour envisager 
qu'on peut oublier ce qu'il y a avant. On est en plein dedans 
actuellement sur les certificats SSL avec SSLv3, RC4 & co pour les 
navigateurs.





Pourquoi pas les DNS root pour commencer ? En éteindre au fur et à
mesure en IPv4 et fermer le dernier à une date raisonnable d'ici 3 à 5
ans ? Pourquoi ne pas ralentir les performances d'IPv4 en aillant une
latence légèrement dégradée vers ceux ci dans le temps ? (même si c'est
pas très beau, disons moins geo-multiplier ces serveurs en IPv4)

Réduire les performances d'IPv4 est impossible, cela va à l'encontre des
SLA des opérateurs.


C'est bien pour ça que je parle de DNS root et non de dégrader le 
service chez les opérateurs eux même, qui eux aussi sont drivés par le 
business (de leurs clients)



Peut-être des tutos massivement diffusés aux sites webs déjà aiderait
aussi sur la manière de mettre une couche IPv6 publique facilement sans
tout changer.

Ce n'est pas un problème de tutos mais de support de l'IPv6 correct dans
les équipements et logiciels.


Je ne suis plus d'accord avec cet argument pour les équipements, il a 
été vrai pendant longtemps, mais maintenant ce n'est plus autant le cas. 
Le problème est maintenant plus sur la couche logicielle et les 
développeurs sont souvent complètement à l'ouest sur le sujet.


Qu'un admin puisse mettre en place des briques permettant d'intégrer une 
plateforme logicielle IPv4 dans un environnement IPv6 reste possible 
dans pas mal de cas du web classique, même s'il reste le gros problème 
des solutions client/serveur proprios (mais ça sera pas la majorité des 
gens du web ça).


Après faudra éduquer les devs, ça prendra encore une bonne génération, 
mais d'un point de vue admin c'est aujourd'hui souvent possible.



Nous les opérateurs on est sensibilisés à tout ça, mais est-ce que ça
touche autant les sites finaux hébergés ce problème ? Parce qu'eux ils
n'y pensent pas trop et leur seul problème c'est de pas perdre du temps
sur ce qui ne rapporte pas de l'argent.

Received: from m.syn.fr (m.syn.fr [195.154.64.190]) by
cabale.usenet-fr.net (Postfix) with ESMTP id 5801798A5949 for
<frnog@frnog.org>; Fri, 19 Feb 2016 17:31:16 +0100 (CET)
Ton mail a été reçu en IPv4 ;)

Ce n'est pas qu'une question de sensibilisation, énormément de personnes
sont sensibilisées mais très peu déploie l'IPv6 en pratique.


Hé le tiens aussi ! Tiens on va faire comme si on était exemplaires, on 
se répond en IPv6 la semaine prochaine ? :)


Je ne sais pas trop qui tu fréquentes dans le monde des sites webs, mais 
de mon côté à chaque fois que je croise un mec qui dev en PHP (par 
exemple, remplace par le langage à la mode qui te plaira le plus), il me 
dit : "ah oui ça a l'air sympa mais je sais pas comment ça marche, ma DB 
le gère pas, c'est la galère si je dois changer".


Autant les admins sont assez chauds pour s'y coller quand tu les 
motives, autant les devs ils tirent bien la gueule à l'idée de faire 
rentrer des adresses dans un autre format différent et de taille bien 
plus longue et tu les sens perdus quand tu leur dit qu'il va falloir 
manipuler des IPv6.


Pour le reste on en revient au problème de départ : Pas d'intérêt 
business, bas de la pile des projets.


Et pour les équipements, pas forcément besoin de tout avoir compatible 
IPv6 pour s'en sortir, pas besoin de tout transformer. Si déjà au départ 
les gens géraient la partie frontale publique, ça suffirait. Après tout 
y'a des gens qui font plein de NAT, c'est pas bcp moins propre d'avoir 
une IPv6 frontale et une plateforme IPv4 derrière et au moins on avance.


Bref pour moi IPv6 au niveau technique pure a besoin de passer plusieurs 
étapes pour s'imposer, pour moi la partie réseau opérateur et 
équipements est quasi accomplie, le plus gros frein reste la partie 
logicielle. J'aimerais bien un retour de profs en université ou école 
aussi pour savoir à quel point IPv6 est enseigné dans les cours, pas en 
cours réseau, mais dans les autres cours.


Frederic


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


Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation

2016-02-19 Par sujet Frederic Dhieux

Salut,

C'est même juste impossible. Toutes les boîtes n'ont pas du LAMP ou 
techno moderne pour leurs services, parfois c'est des boites noires non 
prévues pour évoluer. Et faire un NAT peut ne pas fonctionner si c'est 
le même problème (surtout) côté postes clients.


Libérer un /8 ne changera pas non plus la face du monde, en tout cas ça 
ne fera que reporter le problème un tout petit peu plus loin.


Déjà ce serait bien que tout acheteur ou nouvel opérateur acquérant de 
l'IPv4 présente une plateforme IPv6 ready (minimum préfixes, DNS, site 
web fonctionnel en IPv6) avant d'avoir droit à des IPv4. Ensuite l'idée 
de favoriser IPv6 dans les moteurs de recherche est clairement un vrai 
accélérateur business de l'implémentation IPv6. Si Google fait ça, en 1 
an tous les sites importants sont IPv6 facile.


Je ne comprends toujours pas qu'en 10 ans qu'on prévoit la pénurie, 
aucun effort n'ait été fait pour préparer la possibilité d'utiliser 
240.0.0.0/4 un jour. On se retrouve à réfléchir à des trucs compliqués 
alors qu'un bloc "RESERVED Future use" d'il y a 27 ans ne sera jamais 
exploité.


Egalement ça serait bien un jour de mettre une vraie deadline 
raisonnable mais réelle pour IPv4 et que quelques éléments clés 
d'Internet coupent d'ici cette date.


Pourquoi pas les DNS root pour commencer ? En éteindre au fur et à 
mesure en IPv4 et fermer le dernier à une date raisonnable d'ici 3 à 5 
ans ? Pourquoi ne pas ralentir les performances d'IPv4 en aillant une 
latence légèrement dégradée vers ceux ci dans le temps ? (même si c'est 
pas très beau, disons moins geo-multiplier ces serveurs en IPv4)


A un moment de toute manière il va falloir motiver les gens autrement 
que par des belles paroles, si leur business n'est pas en jeu, ils ne 
bougeront pas. Pour certains ça semble un travail de fou alors qu'on 
parle de mettre au pire un reverse proxy web, des dns et du mail en IPv6 
sur une plateforme IPv4.


Peut-être des tutos massivement diffusés aux sites webs déjà aiderait 
aussi sur la manière de mettre une couche IPv6 publique facilement sans 
tout changer.


Nous les opérateurs on est sensibilisés à tout ça, mais est-ce que ça 
touche autant les sites finaux hébergés ce problème ? Parce qu'eux ils 
n'y pensent pas trop et leur seul problème c'est de pas perdre du temps 
sur ce qui ne rapporte pas de l'argent.


My 2 cents,
Frederic


Le 19/02/2016 16:41, Yann Pretot a écrit :

Salut,



Je ne pense pas qu'on puisse se permettre de couper totalement IPv4 aussi 
rapidement, 2 semaines, c'est clairement insuffisant pour migrer.

Si la plupart (je l'espère) des FAI peuvent déployer rapidement, certains doivent avoir 
des obstacles et contraintes, je pense à du matériel vieillissant chez l'abonné, à une 
architecture qui ne s'y prête pas vraiment... Madame Michu aura des problèmes de toute 
sorte avec "son Internet" qu'il va falloir solutionner, cela prendra du temps.

Tous les abonnés ont des installations différentes, qu'il faut prendre en compte, et qui, 
si rien n'est fait, empêcheront le tout de fonctionner (un exemple tout bête : le fils 
gamer qui a acheté un routeur chez Carrefour pour que sa XBOX "ait un meilleur 
ping").

Il ne faut pas non plus un déploiement à la va-vite qu'on ne peut plus toucher 
après, il faudrait trouver un moyen plus doux, qui forcerait tout le monde à se 
préparer, pas à déployer dans la douleur.



Rome ne s'est pas faite en un jour, le passage global à IPv6 ne se fera pas en 
deux semaines ;)



Yann PRETOT

Association Oxid Telecom





 On ven., 19 févr. 2016 16:24:43 +0100 Josselin Lecocq 
josselin.lec...@quantic-telecom.netwrote 




Salut la liste,

  


Et si au lieu de discuter des soins palliatifs à apporter à l'IPv4

mourant on arrêtait l'acharnement thérapeutique ?

  


Est-ce qu'un IPv6 flag day, sans retour, serait vraiment si impossible

que ça ? Si demain Google, Facebook, Netflix et une poignée de FAI

décidaient de couper l'IPv4, je pense qu'en moins de 2 semaines tout le

monde migrerait vers IPv6, dans la douleur certes, mais qu'importe.

  


Mais peut-être suis-je trop naïf... Quoi qu'il en soit, je trouve que

c'est un bon sujet de discussion pour un vendredi.

  

  


Josselin Lecocq

Quantic Telecom

  

  


Le 19/02/2016 16:14, Jérôme Nicolle a écrit :

 Salut Pierre,



 Le 19/02/2016 14:39, Pierre Colombier a écrit :

 Il me semble probable que les escrocs/rentiers dont tu parles gagnent

 leur combat d'arrière garde mais qu'ils ne feront que précipiter

 l'abandon de leur "ressource rare".



 Je crois que c'est bien là le problème : on a une tendance naturelle, et

 tout à fait défendable, à nous laisser aller doucement vers une voie de

 garage, tout simplement parce qu'on ne prends pas le temps de défendre

 nos positions.



 On est tous sur la brèche dès lors que notre présence est fragilisée,

 c'est à dire qu'on est plus en mesure d'obtenir les ressources dont on a

 besoi

Re: [FRnOG] [TECH] Vraie IP et fausse IP ?

2016-02-17 Par sujet Frederic Dhieux

Hello,

En parlant de notre cher gouvernement, si en bonus (à la place sur 
certains cas) du crédit impôt recherche qui sert à récupérer un peu de 
ses impôts généreusement donnés à l'état ils donnaient une "prime" aux 
sociétés françaises ayant déployé IPv6, en même temps que les moteurs de 
recherche favoriseraient les sites en IPv6 (très bonne idée ça), le 
projet IPv6 en bas de la pile qui prend la poussière face à toutes les 
priorités business avancerait peut-être un peu plus côté fournisseurs de 
contenu.


Tant qu'à verser des sous aux entreprises pour les aider sur leur "R", 
autant que ça soit sur des choses vraiment utiles à tout le monde.


Sinon la pratique de free... Au début Ils ont fait le choix de donner 
une IP par abonné en fixe, de faire du peering ouvert pour avoir une 
bonne qualité de service, maintenant ils saturent leur réseau, font 
payer cher le peering et mutualisent leurs IPv4. Après si les gens 
considèrent toujours Free comme le sauveur parce qu'ils n'ont pas à 
subir quelques Euros de plus à payer chaque mois pour maintenir la 
qualité du service, à un moment effectivement pourquoi s'embêter... (la 
fierté d'avoir un truc propre ne doit plus trop être un objectif de 
free, juste avoir plus d'abonnés lors de la publication des résultats et 
pour ça le marketing et les ventes privées semblent suffire)


Frederic

Le 17/02/2016 11:10, Jérôme BERTHIER a écrit :

Bonjour,

Le 16/02/2016 11:52, Xavier Beaudouin a écrit :
ou le trucs comme les impôts par ex pouvaient au moins avoir un 
service dispo en IPv6


ça fait juste 5 ans que toutes les administrations y ont été 
explicitement invitées :

http://circulaires.legifrance.gouv.fr/pdf/2011/12/cir_34250.pdf

Bon faudrait peut être passer à la phase obligation. :-\
Voilà, voilà...




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


[FRnOG] [TECH] Recherche modèle ADSL2+ simple, fiable et pas (trop) cher

2016-02-04 Par sujet Frederic Hermann
Bonjour, 


Suite à des problèmes récurrents avec nos modems ADSL2+ actuels (des TP-Link 
TD8840T), je cherche de nouvelles références. 


On a juste besoin de petits modems ADSL2+, sans wifi, sans 3G, avec 1 seul port 
10/100, et éventuellement la possibilité de faire de la redirection de ports 
TCP/UDP. 


Notre contrainte principale, c'est qu'ils soient compatibles avec la plupart 
des NRA d'Orange (ce qui n'est pas le cas, par exemple, du TP-Link TD8840 sans 
le 'T'). 


Si vous avez des retours d'expérience sur les TP-Link 8616 et sur les Zyxel 
AMG-1001, ça m'intéresse aussi. 







Cordialement, 



-- 
Frederic Hermann 

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


[FRnOG] [TECH] Recherche modèle ADSL2+ simple, fiable et pas (trop) cher

2016-02-04 Par sujet Frederic Hermann



> J'en ai mis beaucoup, mais je n'en mets plus.
> 


Mon collègue en a commandé 20 pour tester, on verra si on tombe sur une bonne 
série! 

Merci pour ces retours, 

-- 
Frederic Hermann


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


Re: [FRnOG] [BIZ] PCI DSS

2015-12-21 Par sujet Marc Frederic Gomez
Bonsoir,
Il existe des hébergeurs qui disposent de salles certifiés PCI DSS.
Cette certification ne couvrira que le chapitre 9 et pas sur toute son 
intégralité mais c’est déja une galère de moins sur les 12 chapitres PCI.

Le chapitre 9reste le chapitre le plus facile d’une certification PCI DSS. La 
traçabilité des accès physiques sont une promenade de santé par rapport aux 
autres exigences.

Avant de faire son choix verifier sur les sites de Visa & MasterCard qui 
regroupent les certifications PCI DSS et leurs périmètres. Le PCI Council ne 
contient que les prestataires QSA, PCIP, QIR et les apps PA DSS.

Se rapprocher d’un auditeur QSA peut aider grandement dans le choix.

Cordialement
Marc F. Gomez
http://blog.marcfredericgomez.fr



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [FRnOG] [TECH] Don de matériels réseaux

2015-11-23 Par sujet frederic ollivier
tu peux aussi le faire sous forme de don via la taxe d'apprentissage,
c'est possible pour les établissements technique ou technogolique.

http://www.focusrh.com/ecole-entreprise/taxe-apprentissage/versez-votre-taxe-avec-des-dons-en-nature.html
Frédéric Ollivier

NB: Toutes les fautes de frappe, de grammaire, d'orthographe, et de
syntaxe ci-dessus, sont sous licence libre CC-BY. Elles peuvent être
reproduites ou même corrigées sans l'accord préalable de l'auteur.


2015-11-23 10:53 GMT+01:00 Kevin DUBOURG :
> Bonjour,
>
> Je ne sais pas si ce sujet a déjà été abordé mais nous souhaitons donner
> des équipements réseaux à une ou plusieurs écoles.
>
> En effet, ces équipements sont obsolètes pour de la production mais peuvent
> connaitre une deuxième vie dans les mains d'un étudiant.
>
> Cependant, ce pose la question de la législation. Je suis sûr que certains
> d'entre vous font des dons, mais comment est-ce encadré ? comment
> formalisez vous cet échange ?
>
> Notamment sur le fait que les équipements ne passent pas par le processus
> de recyclage écologique. Le don transfert-il la responsabilité in fine de
> la gestion du recyclage ?
>
> Merci d'avance pour vos conseils, nous serions heureux de pouvoir faire
> profiter des écoles de ce matériel qui fonctionne encore très bien.
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


Re: [FRnOG] [TECH] Lien Radio sur 10km

2015-10-17 Par sujet frederic ollivier
J'ai en prod de l'Ubiquity

https://www.ubnt.com/products/




Frédéric Ollivier

NB: Toutes les fautes de frappe, de grammaire, d'orthographe, et de
syntaxe ci-dessus, sont sous licence libre CC-BY. Elles peuvent être
reproduites ou même corrigées sans l'accord préalable de l'auteur.


2015-10-17 1:35 GMT+02:00 David Ponzone :
> Tu peux regarder les produits Infinet qui ont une amplitude de -40 à +60:
>
> http://infinetwireless.com
>
> Si tu veux, je te mets en relation avec le DG France.
>
>
> Le 16 oct. 2015 à 21:14, megagolg...@altern.org a écrit :
>
>> Bonjour,
>>
>> Je suis en train d'étudier le renouvellement de matériels utilisés pour
>> faire des ponts radio, sur quelques kilomètres. Pour le moment en prod,
>> nous avons des Breezenet d'Alvarion. La boite a, semble-t-il coulé et été
>> racheté ou s'est remise de ses déboires. Notre matériel ne semble plus
>> être supporté (pas de doc, de firmware, ni de logiciel pour la conf
>> dispo).
>>
>> Certains de nos sites sont dans des pays a forte chaleur et humidité :
>>> 30°C et >90% d'humidité, en même temps. Pour certain pays sec, on peut
>> aller jusqu'à 60°C à l'intérieur d'une boite en plastique gris clair
>> opaque sur un toit (à l'emplacement de l'antenne). Pour les pays froid, on
>> peut voir des pointes a -40°C.
>> J'ai besoin de matériel qui tiendrait minimum 5 ans. Si je dois aller le
>> changer tout les deux ans, le coût du voyage fera hurler mon boss...
>>
>> Quant au débit, j'ai besoin de 10mbit full duplex minimum, pour 8km maximum.
>>
>> L'amplitude thermique d'une nanostation semble aller (jusqu'à 75°C), pour
>> le froid, je ne sais pas ce qu'il se passe si on va au delà de la
>> préconisation du constructeur. Des idées?
>>
>> Je cherche donc du matériel étanche, avec une plage thermique de -40°C à
>> 75°C. Le matériel de chez Mimosa (B5) commence  à s'approcher, il fait un
>> bon candidat pour des tests.
>> Je regarde Ubiquity, que je connais un peu, et en bien. Mais le problème
>> de la nanostation est le manque d'étanchéité.
>>
>> D'autres suggestions?
>>
>> Megagolgoth.
>>
>>
>>
>> ---
>> 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] Mise en place de serveurs en anycast sur différents continents

2015-10-08 Par sujet Frederic Dhieux


Le 08/10/15 17:24, Raphael Mazelier a écrit :
>
>  
>
> Tu viens de pointer le problème. Tu recherche de la souplesse et un
> opérateur/hébergeur présent world-wide, donc gros. C'est à priori
> antinomique mais je me trompe peut être, et il existe peut être la
> perle rare.
>
> Cdt,

Ah bah c'est le challenge, sinon je poserais pas la question ici ;)
(sait-on jamais, même des idées qui seraient bonnes à prendre)


Le 08/10/15 17:29, David Ponzone a écrit :
> Tu peux essayer BSO.
> Ils ont de la présence sur au moins 3 des 5 lieux que tu veux.
>
>

Yep, je connais bien. Ils ont presque l'emprunte suffisante et la
souplesse pour le proposer c'est vrai, après je pense qu'ils ne
conviendront pas forcément tout de même (capacité sur certains points,
support local en cas de pbm). C'est un peu en pensant à eux que je me
suis dit que c'était peut être jouable.

Après sinon prendre du hosting pur à chaque endroit et prendre du Level
3 en direct sur chaque PoP, mais ça va me coûter cher en cross connects,
logistique, gestion administrative et non bundleisé.

Frédéric


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


Re: [FRnOG] [BIZ] Mise en place de serveurs en anycast sur différents continents

2015-10-08 Par sujet Frederic Dhieux
Hello,

Merci pour ces premiers retours, de ce que je vois Liazo ne sort pas
vraiment de l'Europe de l'ouest et Zayo n'est pas vraiment présent sur
le continent asiatique ou en ME. Vu l'emprunte à couvrir un des 3 tier-1
serait plus simple mais ils sont en général moins souples également sur
ce qu'ils vendent.

Frédéric

Le 08/10/15 17:04, Sylvain sbu a écrit :
> Bonjour
> De mémoire ; je crois que liazo c est faire. Ex Neo.
> Pour le denier point il faut voir avec eux. Mais ça m étonnerait
> Bon courage.
> Sbu


Le 08/10/15 17:05, Arnaud Launay a écrit :
> Le Thu, Oct 08, 2015 at 05:04:08PM +0200, Sylvain sbu a écrit:
>> De mémoire ; je crois que liazo c est faire. Ex Neo.
> Heu ? Zayo non ? :)
>
> Ou alors il s'est passé des trucs :-D
>
>   Arnaud.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


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

2015-09-23 Par sujet frederic ollivier
le client est le roi, non ;-)
Frédéric Ollivier

NB: Toutes les fautes de frappe, de grammaire, d'orthographe, et de
syntaxe ci-dessus, sont sous licence libre CC-BY. Elles peuvent être
reproduites ou même corrigées sans l'accord préalable de l'auteur.


2015-09-23 15:17 GMT+02:00 Julien Escario :
> Le 23/09/2015 15:14, Raphael Jacquot a écrit :
>> On 09/23/2015 03:11 PM, Julien Escario wrote:
>>> Bonjour,
>>> un client me demande de créer un hôte DNS qui pointerait vers 127.0.0.1.
>>> Ceci pour faire du dev sur sa bécane ...
>>
>> il faut lui expliquer que c'est dans /etc/host que ca se mets
>
> Ah, désolé de ne pas l'avoir explicité mais c'est évidemment ce que j'ai 
> répondu.
>
> 'ah oui mais vous savez c'est contraignant : on fini par ne plus savoir si on
> accède à la version en ligne ou en local quand on met en prod'. Bref, 
> feignasse
> mais bon ... client (oserai-je dire que c'est un dev en plus ?).
>
> Julien
>
>


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


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

2015-09-14 Par sujet Frederic Dhieux



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


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


[FRnOG] [JOBS] fcnet recrute un ingénieur réseau

2015-08-01 Par sujet Frederic Petitjean - FCNET
Bonjour



fcnet, 20 ans d'existence, dont le siège social est à Besançon, opérateur 
télécom et hébergeur,  recherche pour étoffer ses équipes afin de faire face à 
son fort développement, un ingénieur systèmes et réseaux.

http://www.fcnet.fr/recrutement.php



Bonne journée



Frédéric


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


Re: [FRnOG] [TECH] Contact free VoIP

2015-07-30 Par sujet Frederic Dhieux

Hello,

Y'a un mec qui passe de temps en temps, pas trop mal placé je crois, il 
s'appelle Xavier Niel. Avec un peu de chance il répondra un soir :D


Frédéric

Le 30/07/2015 15:47, Oceanet - Cédric BASSAGET a écrit :
Ce que mon opérateur m'a toujours dit : c'est a l'appelant qui 
n'arrive pas a joindre un numéro de contacter son fournisseur. Ce que 
j'ai fait.
Mon opérateur (entrant) ne voit pas l'appel arriver sur sa plateforme, 
donc ils ne peuvent pas faire grand chose...


Personne de chez free sur cette ML ...?

Cédric

OCEANET
---
[AGENCE DU MANS]
7, rue des Frênes
ZAC de la Pointe
72190 SARGE LES LE MANS
[t] +33 (0)2.43.50.26.50
[f] +33 (0)2.43.72.21.14

[AGENCE D'ANGERS]
5, rue Fleming
Angers Technopole
49066 ANGERS
[t] +33 (0)2.41.19.28.65
[f] +33 (0)2.52.19.22.00

On 30/07/2015 15:26, David Ponzone wrote:
La démarche est la même: c'est un problème de routage entre 2 OP qui 
ont une interconnexion avec Orange. Ils doivent se parler directement.


David Ponzone



Le 30 juil. 2015 à 15:21, Oceanet - Cédric BASSAGET 
ced...@oceanet.com a écrit :


Ce n'est pas un numéro porté, c'est un numéro d'une tranche 
attribuée par l'arcep.

Cédric

OCEANET
---
[AGENCE DU MANS]
7, rue des Frênes
ZAC de la Pointe
72190 SARGE LES LE MANS
[t] +33 (0)2.43.50.26.50
[f] +33 (0)2.43.72.21.14

[AGENCE D'ANGERS]
5, rue Fleming
Angers Technopole
49066 ANGERS
[t] +33 (0)2.41.19.28.65
[f] +33 (0)2.52.19.22.00


On 30/07/2015 15:09, David Ponzone wrote:
Le plus simple c’est de remonter le problème à ton opérateur (celui 
qui a porté les numéros) et lui demander de remonter un problème de 
porta.


Le 30 juil. 2015 à 14:33, Oceanet - Cédric BASSAGET 
ced...@oceanet.com a écrit :



Ca marche depuis partout sauf depuis le fax free
Pas d'escalade possible selon la hotline, le fax, personne s'en 
sert, ça impacte pas assez de monde pour qu'on s'y intéresse...


OCEANET
---
[AGENCE DU MANS]
7, rue des Frênes
ZAC de la Pointe
72190 SARGE LES LE MANS
[t] +33 (0)2.43.50.26.50
[f] +33 (0)2.43.72.21.14

[AGENCE D'ANGERS]
5, rue Fleming
Angers Technopole
49066 ANGERS
[t] +33 (0)2.41.19.28.65
[f] +33 (0)2.52.19.22.00


On 30/07/2015 14:17, David Ponzone wrote:
Si tu appelles la SDA depuis une ligne voix Free, ça marche ?
Et depuis un autre alternatif qui utilise l’APNF ?

Si tu as des échecs aussi, c’est que c’est ta SDA portée qui 
n’est pas déclarée correctement à l’APNF.



Le 30 juil. 2015 à 14:15, Oceanet - Cédric BASSAGET 
ced...@oceanet.com a écrit :


Le fax sortant free ne marche pas vers la SDA en question
Si j'envoie un fax vers un autre numéro, ça fonctionne
Si j'appelle la SDA depuis une ligne témoin la SDA fonctionne.

En gros elle ne marche pas depuis le fax free, mais pas de 
problème depuis ailleurs.

Je ne peux pas tester le fax entrant pour l'instant.

Cédric

OCEANET
---
[AGENCE DU MANS]
7, rue des Frênes
ZAC de la Pointe
72190 SARGE LES LE MANS
[t] +33 (0)2.43.50.26.50
[f] +33 (0)2.43.72.21.14

[AGENCE D'ANGERS]
5, rue Fleming
Angers Technopole
49066 ANGERS
[t] +33 (0)2.41.19.28.65
[f] +33 (0)2.52.19.22.00


On 30/07/2015 14:10, David Ponzone wrote:
C’est le sortant de Free qui ne marche pas ?
Si tu envoies un fax vers ton num de portable par exemple, tu 
reçois l’appel  ?
Et l’entrant vers ta SDA fax Free (dans l’autre sens donc) 
marche de manière parfaite ?



Le 30 juil. 2015 à 13:55, Oceanet - Cédric BASSAGET 
ced...@oceanet.com a écrit :


Bonjour,
Après avoir passé 30 minutes au tel avec le 3244 et avoir eu 
comme résultat à mon problème votre cas est isolé, du coup on 
ne fera rien pour corriger votre problème, et en plus le fax 
est utilisé par très peu de gens..., je suis à la recherche 
d'un contact chez free qui pourrait m'aider a corriger un 
problème de routage de SDA pour de l'envoi de fax.
La SDA fonctionne bien depuis divers lignes témoin (orange, 
sfr, même free mobile !) mais impossible d'envoyer un fax 
dessus depuis l'interface free (l'appel n'arrive pas chez nous).


Merci pour vos retours en MP.
Cédric


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



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



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


Re: [FRnOG] [ALERT] OVH down ?

2015-07-29 Par sujet Frederic Dhieux


Le 29/07/15 16:23, Gaëtan Allart a écrit :
 Sans vouloir troller, on ne peut pas mettre sa production sur un hébergeur 
 low-cost et ne pas tolérer quelques minutes d’indisponibilité.

 Gaëtan

Hello,

Je ne peux qu'être d'accord, c'est un choix conscient et il faut
l'assumer. Je ne comprends pas qu'on puisse autant se scandaliser pour
un service low cost, les gens veulent toujours le beurre et l'argent du
beurre.

Tout a un prix, souvent lié à celui que le client paye (surtout à ce
qu'il ne paye pas en fait).

Frédéric


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


Re: [FRnOG] [ALERT] OVH down ?

2015-07-29 Par sujet Frederic Dhieux



Le 29/07/2015 18:33, Olivier Varenne a écrit :

Mouais.

Sans vouloir prendre la défense d'OVH, ils sont quand même honnêtes et avoue 
que l'erreur vient d'un problème humain
Combien de boites se seraient retranchées dans un silence complet voir auraient 
accusé le voisin pour ne pas subir les foudres des clients ?


Ne nous méprenons pas, je ne critique pas OVH en disant que c'est du low 
cost, ils font très bien leur métier pour ce qu'ils proposent et le 
rapport qualité/prix est plutôt bon. On peut aussi dire de même pour 
Online dont le service est très bon par rapport au prix.


Et OVH a souvent fait preuve d'une certaine transparence appréciable 
quand ils font des erreurs.


C'est surtout les clients qui se scandalisent alors qu'ils payent une 
misère tous les mois pour plein de services que je critique :)


Frédéric


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


Re: [FRnOG] [ALERT] OVH down ?

2015-07-29 Par sujet Frederic Robert
On Wed, Jul 29, 2015 at 03:53:41PM +0200, Alexis VACHETTE wrote:
 Même constat, sauf que ça commence à faire beaucoup.

Erreur humaine en plus. :)

-- 
Frederic Robert


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


  1   2   3   4   5   >