Re: [FRnOG] [TECH] Solution callcenter

[Simon Perreault]

Le 2017-05-31 à 12:30, Francois Prems a écrit :
> je recherche une solution qui me permette de mettre rapidement en ligne un
> callcenter pour un service client avec les fonctionnalités suivantes :

On fait presque tout ça!

http://jive.com/products/contact-center/

> - Prise d'appels entrants avec file d'attente, IVR, et bonne gestion des
> agents (ACD)

Oui.

> - Enregistrement des appels

Oui.

> - Double écoute, conférence

Oui, oui.

> - Statistiques orientées call center (durées d'appels, temps d'attente,
> temps d'occupation des agents, etc... )

Oui.

> - En SIP (ou client webrtc directement intégré dans interface de l'agent)

Oui, les deux.

> - Campagnes d'appels sortants (optionnel)

Non.


Mais on n'est pas (encore) en France! :(

-- 
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | +1 418 478 0989 ext. 1241 | sperrea...@jive.com


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

Re: [FRnOG] [TECH] Sotfphone au lieu de hardphone derrière livebox business 132

[Simon Perreault]

Le 2017-02-06 à 11:04, Michel Py a écrit :
> Moi j'ai une question con (comme d'habitude) : c'est quoi comme marque de 
> téléphone IP que les opérateurs installent, ces jours-ci ? ou est-ce que le 
> client a le choix entre plusieurs modèles ?
> 
> J'ai 200 téléphones à changer a la fin de l'année, je m'oriente vers du 
> Grandstream.

http://jive.com/phones/

Les préférés de mes ingénieurs en UA, c'est les Yealink. :)

-- 
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | +1 418 478 0989 ext. 1241 | sperrea...@jive.com


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

[FRnOG] [JOBS] Jive Communications - Ingénieur de réseau sénior - Amérique

[Simon Perreault]

Très chère FRNOG,

Jive Communications , une société américaine de VoIP
cloud, est à la recherche d'un ingénieur de réseau sénior. Le candidat
choisi deviendra maître du réseau IP de Jive, de ses peerings BGP, des
réseaux intra datacenter, des liens inter datacenter, des VPNs, des
liens MPLS avec nos plus gros clients, etc. Avec son équipe, il en
gèrera l'opération, planifiera et mènera son évolution.

Sujets chauds:
- ajustement des annonces BGP selon les mesures live de sondes réseau
distribuées
- détection et blocage des tentatives de fraude en temps réel
- développement d'un produit à la Direct Connect

Le candidat devra démontrer une solide expérience en ingénierie des
réseaux applicable au sujets ci-dessus.
Connaissances en VoIP non nécessaires mais appréciées.
Anglais bon à très bon exigé. (L'accent on s'en fout, mais il faut
pouvoir être 100% fonctionnel en anglais écrit et parlé.)

Le poste est à pourvoir physiquement à l'endroit de votre choix parmi
ceux-ci:

Québec, Québec, Canada
Montréal, Québec, Canada
Orem, Utah, USA

Simon


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

[FRnOG] [JOBS] Quitte ou double

[Simon Perreault]

Chers FRNOGiens,

En juillet 2015, j'envoyais ce message:

> Jive Communications (jive.com) est une société américaine de VoIP cloud.
> 
> Mon équipe, basée à la magnifique ville de Québec, au Canada, développe
> le cœur de la plateforme RTP/SIP/WebRTC. Le code est un mélange de
> C/C++/Java.
> 
> Je cherche un ou deux programmeurs, plutôt séniors, avec expérience de
> la VoIP et/ou de la programmation réseau pour se joindre à l'équipe. Si
> vous êtes Français et diplômé, c'est d'habitude pas trop compliqué pour
> obtenir un visa de travail. Sinon, désolé, je ne sais pas.
> 
> La dernière fois que j'ai annoncé un emploi sur FRNOG, j'ai trouvé une
> perle rare. J'ai foi en toi, FRNOG! :)

Hé bien, devinez quoi, j'ai trouvé une deuxième perle rare qui s'est
merveilleusement intégrée à l'équipe et qui semble jusqu'à maintenant
être charmée par Québec. FRNOG, j'avais raison d'avoir foi en toi! Tu ne
m'as pas déçu!

Alors FRNOG, tiens-toi bien, quitte ou double... J'ENGAGE! À QUÉBEC!
Front-end, back-end, full-stack, je m'en fous! C, Java, Go, Python,
Ruby, JavaScript, tout est bon! Dev, DevOps, sysadmin, ingénierie de
réseau, DBA, mobile, QA, scrum master, j'ai besoin de tout! Des tonnes
de projets diversifiés et intéressants! Une entreprise dynamique en
croissance fulgurante! Conditions d'emploi qui font l'envie de tous!
Venez! Venez! Venez!

(Si j'en vois un me demander le salaire, je le mets immédiatement dans
la catégorie "n'y pige que dalle". Néanmoins, pour les curieux, il
devrait suffire de mentionner qu'on est en Amérique, ici.)

Simon


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

Re: [FRnOG] [TECH] PAT et ré-utilisation du port externe

[Simon Perreault]

Oui c'est un comportement bien connu et documenté. En terminologie IETF,
c'est du Address and Port-Dependent Mapping [RFC4787]. Et c'est mal:

   REQ-1:  A NAT MUST have an "Endpoint-Independent Mapping" behavior.

   Justification:  In order for UNSAF methods to work, REQ-1 needs to be
  met.  Failure to meet REQ-1 will force the use of a UDP relay,
  which is very often impractical.

En résumé, le problème est que les méthodes de traversée de NAT à la
STUN ne fonctionnent pas avec ce genre de NAT.

Simon

Le 2016-01-05 16:10, David Ponzone a écrit :
> Barbu(e)s,
> 
> Je suis tombé sur un cas de figure intéressant que je ne suis pas sûr d’avoir 
> déjà croisé avant:
> un PAT qui utilise parfois simultanément plusieurs fois le même port externe 
> pour des flux RTP vers des couples adresses/ports distants différents.
> 
> Par exemple, je vois au même moment les flux RTP suivants:
> IP-PUBLIQUE-CPE:8000   <——> IP-DISTANTE:42000
> IP-PUBLIQUE-CPE:8000   <——> IP-DISTANTE:42008
> 
> C’est un mode de PAT que peu de constructeurs utilise (selon mon expérience).
> Je me demande si d’autres ont croisé ceci, car cela me semble être un niveau 
> de complexité tellement inutile dans un routeur CPE.
> Dans mon cas, c’est un routeur GPON Alcatel.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 


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

Re: [FRnOG] [TECH] QOS voix switch cisco

[Simon Perreault]

Le 2015-10-27 03:23, David Ponzone a écrit :
> Es-tu vraiment sûr que c’est sur le switch que tu risques le plus d’avoir de 
> la contention ?
> A priori, ton premier problème, ça va être sur le lien WAN, mais j’ai 
> peut-être mal compris le besoin.

On peut faire la QoS n'importer où à condition de shaper le trafic un
peu en-dessous (~95%) de la capacité maximale du point de contention.
Cela déplace le point de contention là où la QoS est appliquée.

Par contre, je pense (pas certain) que la 2960 ne fait pas de shaping.

Simon


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

Re: [FRnOG] [JOBS] Recherche CDI ingénieur système/réseau

[Simon Perreault]

Le 2015-09-25 08:31, Simon Perreault a écrit :
> - Prends une autre photo sans lunettes de soleil. (À moins que ce soit
> des lunettes pour aveugle, auquel cas je suggèrerais d'éliminer la photo.)

Pour être clair, la raison pour laquelle je suggère d'éliminer la photo
est d'éviter que des employeurs potentiels s'imaginent que tu es un
jeune con qui met ses lunettes de soleil sur une photo de CV. :)

Simon


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

Re: [FRnOG] [JOBS] Recherche CDI ingénieur système/réseau

[Simon Perreault]

Joli CV. Si tu étais de l'autre côté de l'Atlantique je serais intéressé.

Deux remarques pour t'aider et/ou troller:

- Prends une autre photo sans lunettes de soleil. (À moins que ce soit
des lunettes pour aveugle, auquel cas je suggèrerais d'éliminer la photo.)

- Enlève la mention "23 ans".

Simon

Le 2015-09-25 04:52, Alexis Lameire a écrit :
> Bonjour la liste,
> 
> Jeune diplômé de l'ENSIIE, école d'ingénieurs à Évry, je suis actuellement
> à la recherche d'un poste d'administrateur système/réseau dans la région
> parisienne.
> 
> Utilisateur Linux depuis presque 10 ans, et passionné des technologies
> libres, j'ai eu l'occasion de mettre en pratique mes connaissances acquises
> scolairement et en autodidacte au sein de plusieurs entreprises dans le
> domaine de l'administration système et réseau.
> 
> Lors de ces missions, j'ai eu l'occasion de manipuler divers outils tels
> que les serveurs web, les bases de données, les outils de monitoring et de
> virtualisation. J'ai aussi travaillé sur du matériel réseau : Mikrotik,
> Netgear et Openwrt. Enfin je maîtrise le scripting shell (bash/sh) ainsi
> que les langage python et PHP.
> 
> 
> Si vous souhaitez en apprendre plus sur mon profil, je vous prie de bien
> vouloir trouver mon CV à l’adresse suivante :
> http://lameire.iiens.net/cv/cvAlexisLameire.pdf
> 
> Si vous souhaitez obtenir des informations complémentaires sur mon profil,
> ou convenir d'un entretien, n'hésitez pas à me contacter.
> 
> Cordialement
> Alexis Lameire
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 


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

[FRnOG] [JOBS] Programmeur VoIP à Québec

[Simon Perreault]

Chers FRNOGiens,

Jive Communications (jive.com) est une société américaine de VoIP cloud.

Mon équipe, basée à la magnifique ville de Québec, au Canada, développe
le cœur de la plateforme RTP/SIP/WebRTC. Le code est un mélange de
C/C++/Java.

Je cherche un ou deux programmeurs, plutôt séniors, avec expérience de
la VoIP et/ou de la programmation réseau pour se joindre à l'équipe. Si
vous êtes Français et diplômé, c'est d'habitude pas trop compliqué pour
obtenir un visa de travail. Sinon, désolé, je ne sais pas.

La dernière fois que j'ai annoncé un emploi sur FRNOG, j'ai trouvé une
perle rare. J'ai foi en toi, FRNOG! :)

Simon Perreault
Directeur, Jive Communications Canada


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

Re: [FRnOG] [TECH] Une proposition de loi veut imposer l'IPv6 dans

[Simon Perreault]

Le 2014-07-30 15:10, fr...@jack.fr.eu.org a écrit :

Vla un exemple de chez IBM:
http://pic.dhe.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.hale001%2Fdqx2ipv6d0141018898.htm


Exemple à ne pas suivre.

Simon


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

Re: [FRnOG] [TECH] Une proposition de loi veut imposer l'IPv6 dans les appareils au 30 juin 2015

[Simon Perreault]

Le 2014-07-30 14:25, fr...@jack.fr.eu.org a écrit :

Ben ouais, n'empêche que pour la majorité des programmes, c'est niquel;
Si je prends un truc comme apache, par exemple :
tcp6   0  0 :::80   :::*
LISTEN  0  225893833


Et la majorité des gens ne disent pas de conneries sur FRNOG.

Simon


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

Re: [FRnOG] [TECH] Une proposition de loi veut imposer l'IPv6 dans les appareils au 30 juin 2015

[Simon Perreault]

Le 2014-07-30 13:31, fr...@jack.fr.eu.org a écrit :

Mais bien sûr, comme si c'était aussi simple. J'aime bien les points de
suspension qui cachent les 9.5/10èmes de l'iceberg.


Puis-je être méchant ?
Si ton application (niveau 7) se soucie du niveau 4, c'est que tu es
programmeur de bien piètre qualité.


Bienvenue dans le monde réel.


Non seulement ça, mais en plus s/AF_INET/AF_INET6/g est bien quelque

chose que l'on *ne doit pas* faire!

Ok, encore une affirmation à la rache.
T'as des arguments ?

Pour info, AF_INET ne permet que l'IPv4, alors que AF_INET6 inclue les
deux protocoles.


Tu penses aux adresses IPv4-mapped, lesquelles, primo ne sont pas 
disponibles sur tous les OS, et secundo sont considérées comme un hack 
qu'on ne devrait utiliser qu'en dernier recours. Pour exemple, 
l'utilisation des adresses IPv4-mapped dans OpenVPN est la raison pour 
laquelle leur support IPv6 est horriblement limité. Ils planifient 
d'ailleurs de s'en débarasser, mais ça sera un changement architecturel 
majeur. En gros, il faut que le soft passe de 1 socket à N sockets. Tout 
est affecté. J'ai observé la même chose lorsque j'ai porté Asterisk à 
IPv6. Les IPv4-mapped, c'est de la merde pour tourner les coins ronds.


Simon


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

Re: [FRnOG] [TECH] Une proposition de loi veut imposer l'IPv6 dans les appareils au 30 juin 2015

[Simon Perreault]

Le 2014-07-30 12:29, Jérémie Courrèges-Anglas a écrit :

- 's/AF_INET/AF_INET6/g', le truc que tout programmeur devrait faire
>depuis 10 ans
>- utiliser des FQDN et pas des IP: idem
>- ..

Mais bien sûr, comme si c'était aussi simple. J'aime bien les points de
suspension qui cachent les 9.5/10èmes de l'iceberg.


Non seulement ça, mais en plus s/AF_INET/AF_INET6/g est bien quelque 
chose que l'on *ne doit pas* faire!


Simon


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

Re: [FRnOG] [JOBS] Administrateur système Linux chez Planet-Work

[Simon Perreault]

Le 2014-07-23 17:23, Jérôme Nicolle a écrit :
> Après tout, qui parmi vous oserai afficher son salaire sur son badge du
> prochain FRnOG ?

Un sondage anonyme annuel pourrait être extrêmement utile.

Simon


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

Re: [FRnOG] [JOBS] Administrateur système Linux chez Planet-Work

[Simon Perreault]

Le 2014-07-22 18:36, Simon Perreault a écrit :
> De ce côté-ci on n'affiche presque jamais le salaire offert, ni même une
> fourchette. Je ne pense pas que c'est spécifique à la France.

Plusieurs exemples, gracieuseté de mon employeur, illustrant mon propos:

http://jive.com/careers/

Simon


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

Re: [FRnOG] [JOBS] Administrateur système Linux chez Planet-Work

[Simon Perreault]

De ce côté-ci on n'affiche presque jamais le salaire offert, ni même une
fourchette. Je ne pense pas que c'est spécifique à la France.

Simon

Le 2014-07-22 18:28, David Ponzone a écrit :
> Je ne vais pas ajouter de l’huile sur le feu, mais les réactions de certains 
> m’ont rappelé un détail que j’avais déjà remarqué il y a longtemps.
> Dans les offres d’emploi proposées par des sociétés étrangères, en France ou 
> pas, il y a très souvent un salaire minimum, ou une fourchette.
> Quasi systématiquement, d’après mes observations, quand l’annonce vient d’une 
> boite française, il n’y a aucun salaire précisé, comme si chez nous, on se 
> réservait la possibilité de tirer le salaire vers le bas au maximum lors des 
> entretiens.
> Ce n’est pas cohérent, puisque généralement, quand on propose un poste, c’est 
> qu’on a un budget prévu pour le poste: un minimum parce qu’on veut attirer 
> des éléments intéressants, et un maximum parce qu’on veut pas y laisser sa 
> boite.
> 
> J’espère que c’est plus le signe d’une situation économique difficile que 
> d’une culture d’entreprise des employeurs français.


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

Re: [FRnOG] [JOBS] Administrateur système Linux chez Planet-Work

[Simon Perreault]

Je ne comprends pas ces réactions qui sont pourtant courantes sur frnog.
Si la description du poste vous laisse froid, passez votre chemin. Où
est le problème?

C'est la crise?

Simon

Le 2014-07-22 15:21, m3g4g0lG0t|-| a écrit :
> L'offre ressemble à beaucoup d'offres du meme genre en France.
> Bizarrement je n'ai pas souvenir d'en avoir vu des comme ça en Europe
> Francophone (hors France).
> 
> M. Gautier de chez Planet Works, pouvez-vous expliquer pourquoi vous
> requerrez tant de compétences sur un seul poste? Si j'ai compris, vous
> voudriez un généraliste plutôt qu'un spécialiste?
> 
> Quant à la rémunération, à part "selon le profil" ou le "suivant le
> marché", en effet, vu les exigences vous savez déjà quel type vous
> pourriez plutôt retenir en terme d’expérience et de compétences, combien
> le rémunérerez-vous?
> 
> Nous ne sommes pas vendredi, je ne lâche pas (encore) le troll; merci de
> répondre de manière constructive.
> 
> Megagolgoth-
> 
> Le 22/07/2014 20:03, Pierre-Elliott Bécue a écrit :
>> On mar. 22 juil. 2014 à 19:03:09, Mini Fab wrote:
>>> Et bien sur le tout payé au smic :)
>>
>> C'est un poil gratuit. :p
>>
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Impossible de migrer les Users/Group OpenBSD 4.6 vers OpenBSD 5.5

[Simon Perreault]

Le 2014-05-02 10:03, Simon Perreault a écrit :
> Le 2014-05-02 09:45, Laurent Laurent a écrit :
>> J'ai un problème pour récupérer mes Users/Group en migrant d'un OpenBSD 4.6
>> vers 5.5 (Le serveur est utilisé en tant que serveur SFTP, donc beaucoup de
>> comptes et je ne peux pas les taper à la main surtout que la probabilité
>> que les utilisateurs ayant un compte dessus aient perdus leur mdp est
>> grande :) ).
> 
> Deux observations:
> 
> 1. Le processus d'upgrade supporté est de passer par chaque version
> intermédiaire. Pour 4.6 à 5.5, ça fait beaucoup de versions, mais
> faisable en une journée (c'est très répétitif, rapidement on se fait la
> main). Pas mal certain que ça éliminerait le problème, ou du moins ça
> permettrait de déterminer exactement à quelle version ça coince.
> 
> 2. Si tu pouvais envoyer une ligne de /etc/master.passwd correspondant à
> un compte problématique, ça aiderait pour le diagnostic.

Et une troisième:

3. As-tu bien suivi le guide d'upgrade pour 5.5?

http://www.openbsd.org/faq/upgrade55.html

En particulier cet extrait:

> Prepare for first reboot after time_t change. The time_t change requires 
> rebuilding a some files, including the /etc/master.password file. Without 
> this being done, you cannot log in after the reboot! This is done 
> automatically by the upgrade script, but has to be done manually on first 
> boot after upgrade by creating a /etc/rc.firsttime:
> 
> echo "/usr/sbin/pwd_mkdb -d /etc /etc/master.passwd" >>/etc/rc.firsttime
> echo "cp /dev/null /var/log/lastlog" >>/etc/rc.firsttime
> echo "cp /dev/null /var/log/wtmp" >>/etc/rc.firsttime
> 
> This will regenerate the password file and delete a couple files that will 
> not work after the time_t change. 

Simon


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

Re: [FRnOG] [TECH] Impossible de migrer les Users/Group OpenBSD 4.6 vers OpenBSD 5.5

[Simon Perreault]

Le 2014-05-02 09:45, Laurent Laurent a écrit :
> J'ai un problème pour récupérer mes Users/Group en migrant d'un OpenBSD 4.6
> vers 5.5 (Le serveur est utilisé en tant que serveur SFTP, donc beaucoup de
> comptes et je ne peux pas les taper à la main surtout que la probabilité
> que les utilisateurs ayant un compte dessus aient perdus leur mdp est
> grande :) ).

Deux observations:

1. Le processus d'upgrade supporté est de passer par chaque version
intermédiaire. Pour 4.6 à 5.5, ça fait beaucoup de versions, mais
faisable en une journée (c'est très répétitif, rapidement on se fait la
main). Pas mal certain que ça éliminerait le problème, ou du moins ça
permettrait de déterminer exactement à quelle version ça coince.

2. Si tu pouvais envoyer une ligne de /etc/master.passwd correspondant à
un compte problématique, ça aiderait pour le diagnostic.

Simon


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

Re: [FRnOG] [TECH] Impossible de migrer les Users/Group OpenBSD 4.6 vers OpenBSD 5.5

[Simon Perreault]

Le 2014-05-02 09:48, Clement Cavadore a écrit :
> On Fri, 2014-05-02 at 15:45 +0200, Laurent Laurent wrote:
>> PS : On est peut-être Vendredi mais c'est une vrai demande :)
> 
> ... demande qui aurait plutôt sa place sur FRSaG que sur FRNoG, imho :-)

...ou encore mieux: m...@openbsd.org

(C'est une liste en anglais mais il y a plein de francophones qui y sont
incrits, dont plusieurs core devs, donc aucun problème à commencer par
"Sorry for posting in French but my English level is not quite good
enough...")

Simon


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

Re: [TECH] Re: [FRnOG] Re: [ALERT] Nouvelle faille openssl

[Simon Perreault]

Le 2014-04-23 09:11, Jérémie Bouillon a écrit :
> Je crains que l'effet «annoy hipster» (assez insultant au passage) n'ait
> pas l'effet escompté par ces braves gens.

Au contraire, ça marche parfaitement, comme ton expérience en témoigne.

Simon


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

Re: [FRnOG] [FRNOG][TECH] Outils de transferts de fichiers sur UDP

[Simon Perreault]

BitTorrent?

Le 2014-04-18 15:43, Erik LE VACON a écrit :
> Bonsoir à tous,
> Je vous contacte dans le cadre d'une recherche de solutions de
> transferts de données sur réseaux à latence importante.
> 
> Les volumétries concernées sont de plusieurs téras de données par jour,
> en transcontinental (latence de 85 à 150ms en fonction des points nous
> concernant).
> 
> La majorité des transferts se faisant traditionnellement en TCP (rsync,
> ftp, scp et autres), avec les problématiques connues générées par
> l'augmentation du RTT,  j'ai donc tenté des alternatives sur différentes
> solutions de transfert sur UDP, comme Tsunami-UDP, RBUDP et GridFTP, en
> gratuit , et Aspera en payant.
> 
> Je suis passé y compris par de la "tuyauterie maison from scratch" à
> base de scripts NC, PIGZ et TAR, avec multi-threads  pour le transfert...
> 
> Bref, dans tous les cas, le taquet n'est pas atteint, mais les taux de
> transferts sont intéressant, notamment sur Tsunami, mais n'atteignent
> que péniblement les 500-600mbps sur le gigabit dont nous disposons
> actuellement, malgré des raids 0 vides hors fichiers pour test, de
> chaque côté, étant capables de gérer les 100-110MBps attendus, et un
> circuit vide.
> 
> Précisons que les tests ont été menés y compris "directement en sortie
> des RAD" de chaque côté en off-hours, pour détecter d'éventuels pbs de
> conf sur les appliances de sécu.
> 
> Donc, la question: avez vous rencontré de telles problématiques, et si
> oui, quelles autres solutions, de type OpenSource ou à défaut peu
> couteuses, avez vous adopté pour faire face ? S'entend, solutions autres
> que les technologies de WAN-optim embarquées sur certaines baies récentes ?
> 
> Merci de vos retours,
> 
> Excellent weekend à tous,
> 
> 


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

Re: [FRnOG] [MISC] Audit TrueCrypt

[Simon Perreault]

Le 2014-04-17 03:36, Thibaut MARTIN a écrit :
> Est-ce que quelqu'un a eu le temps de regarder les retours de l'Audit
> TrueCrypt ?
> https://opencryptoaudit.org/reports/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Security_Assessment.pdf

Je viens de le parcourir en diagonale. Le plus grave problème qu'ils ont
trouvé (page 14) est l'algo PBKDF2 qu'ils suggèrent de remplacer par
scrypt. Si c'est ça le plus grave problème, autant dire qu'il n'y a pas
de problème.

Simon


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

Re: [FRnOG] [TECH] VLAN maximum sur une interface eth linux

[Simon Perreault]

Le 2014-04-15 15:23, Ludovic LACOSTE a écrit :
> Il me semblait que quoiqu
> 'il arrive la limite était de 4096, et non illimité, mais je m'en remet
> aux personnes de valeurs ...

Je répète:

Oui bien sûr ça dépend du protocole. Linux lui-même n'impose aucune limite.

Dire des conneries n'est pas une de mes valeurs. :D

Simon


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

Re: [FRnOG] [TECH] VLAN maximum sur une interface eth linux

[Simon Perreault]

Le 2014-04-15 15:11, Antoine Durant a écrit :
> En fait j'ai trouvé plusieurs réponses qui n'ont pas la même valeur...

Les réponses différentes de la mienne n'ont effectivement aucune valeur. ;)

Simon


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

Re: [FRnOG] [TECH] VLAN maximum sur une interface eth linux

[Simon Perreault]

Le 2014-04-15 14:29, MM a écrit :
> Sauf que c’est faux aussi - soyons pointilleux.
> Ça dépend au moins du protocole utilisé :P
> 802.1q -> 12 bits dans le Tag Protocol Identifier (priorité 3, 1 pour la
> compatibilité tokenring, puis l’ID de vlan -> 4096 possibilités

Oui bien sûr ça dépend du protocole. Linux lui-même n'impose aucune limite.

> Concernant cette limite, peut être était-elle valable à l’époque ou
> cette réponse avait été écrite …
> Il est effectivement possible que cette limite ait sauté depuis …

Probable. No sé.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

Re: [FRnOG] [TECH] VLAN maximum sur une interface eth linux

[Simon Perreault]

Le 2014-04-15 14:12, MM a écrit :
> Un petit coup de google me répond ceci :
> As VLANs are created over minor-devices in Linux, the limit should be 256 
> VLANs per ethernet adapter.

Sauf que c'est faux. Il n'y a pas de limite.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

Re: [FRnOG] Re: [ALERT] Nouvelle faille openssl

[Simon Perreault]

Le 2014-04-12 10:42, Jean-Yves Faye a écrit :
> La faille dont il parle, c'est probablement un truc vague du genre :
> "OpenSSH sur un OS avec SMP est troué de toute façon" ou "Le seul BSD qui
> permet de faire de la sécu c'est OpenBSD". Donc si vous croyez Theo de
> Raadt sur parole, vous pouvez changer tous vos Juniper contre des OpenBSD
> avec OpenBGPD, c'est fait pour.

Oui. Ou plus généralement: tout OS qui n'est pas OpenBSD est troué.
Selon le point de vue, ça peut même être considéré comme vrai. Mais en
pratique, faut gérer le risque, et "troué" n'est pas blanc ou noir mais
bien un continuum. Bref, oui, probablement qu'OpenSSH est plus
sécuritaire sur OpenBSD qu'ailleurs, mais ça ne m'empêchera pas de
dormir la nuit.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

Re: [FRnOG] [TECH] Scripts TCL / Cisco IOS

[Simon Perreault]

Le 2014-02-27 13:36, Michel Py a écrit :
> Au fait, c'est quoi le mot Français pour "scalable" ?

http://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?srchtxt=scalable

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

Re: [FRnOG] [TECH] Choix Antivirus

[Simon Perreault]

Trop gros, trop facile. Peut faire mieux.

Simon

Le 2014-02-19 06:11, err404 a écrit :
> je ne comprend pas cet acharnement therapeutique sur ces trucs qui
> prétendent être "Pro", qui coûtent un prix non nul
> qui ne sont pas libres, et qui ne sont même pas capable de se protéger
> eux même des dangers de l'Internet, ou des soit disant "virus".
> 
> déjà je ne crois pas aux virus, parce que j'ai beau demander à en voir
> un (un binaire à defaut des sources),
> je ne vois que des malwares, des chevaux de troies etc.
> brefs des trucs qui nécessite une action volontaire de la part de ce qui
> est situé entre la chaise et le clavier.
> 
> la selection naturelle serait de laisser pourrir tous ces windows.
> 
> bon, si on parle des failles suites à de mauvaises configuration, par
> exemple les serveurs ntp et leur amplification, on en
> revient encore aux réglages par defaut qui sont foireux dans beaucoup de
> solution propriétaires parce qu'il est difficile voire
> impossible de corriger ces firmwares buggués, mais ce ne sont pas des
> virus, quoique... un firmware non libre...
> 
> il n'y aurait pas toutes ces histoires de virus si les gens étaient plus
> souvent sous un OS libre,
> que ce soit GNU/Linux, freeBSD, OpenBSD, ou à la limite Androïd.
> 
> d'ailleurs, puisque certains d'entre vous font tourner des antivirus sur
> des routeurs,
> je veux bien que vous me tranmettiez les virus que vous avez pu trouver,
> je suis tranquille, les virus n'existent que dans les plaquettes
> publicitaires.
> 
> la meilleur façon de se protéger des soit disants virus, c'est de ne pas
> faire tourner windows (qui est le plus gros virus)
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 


-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

Re: [FRnOG] [TECH] Interco BGP sur subnet RFC1918 : on en est arrivé là ?

[Simon Perreault]

Le 2013-11-20 08:47, Jérôme Nicolle a écrit :

Je suis en train de monter un transit pour multihommer un client, et son
autre transitaire m'a donné un /31 en 172.17 sans y voir le moindre
problème.


Quid d'une interco en 169.254/16?

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

Re: [FRnOG] [TECH] IPv6 sur le réseau privé

[Simon Perreault]

Le 2013-11-18 13:09, Gilles Mocellin a écrit :

Est-ce-possible de se réserver une plage IPv6 global, et de la conserver
quelque soit l'opérateur ?


C'est pareil à IPv4. Donc: un préfixe PI + BGP, ou NAT. Avec la 
différence qu'on peut faire un type de NAT plus "gentil" appelé NPT66 
[RFC6296].


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

[FRnOG] Re: [TECH] NAT, IPv6 et autohébergement

[Simon Perreault]

Le 2013-09-30 15:20, Stephane Bortzmeyer a écrit :
>> Ça ressemble à un NAT qui ne fait pas de "hairpinning".
> 
> « Virage en épingle à cheveux » en français. (Le paquet va vers la box
> puis repart vers le réseau local.)

« boîte » en français. ;)

Simon


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

Re: [FRnOG] [TECH] NAT, IPv6 et autohébergement

[Simon Perreault]

Le 2013-09-30 14:53, Philippe Guillebert a écrit :
> Bonjour à tous,
> 
> Un petit sujet peut-être un peu amateur pour cette liste, mais qui concerne
> ipv6, donc je me lance :
> 
> J'essaye d'auto-héberger un petit blog chez moi derrière ma box. j'ai une
> entrée DNS mondomaine.com qui pointe sur l'adresse publique fixe de ma
> (free)box.
> 
> Du coup, ca marche très bien, sauf depuis l'intérieur du réseau NATé par la
> box, ce qui est gênant pour mettre à jour le blog en pantoufles à la maison.

Ça ressemble à un NAT qui ne fait pas de "hairpinning".

https://tools.ietf.org/html/rfc4787#section-6

> Qu'a cela ne tienne, puisque le NAT c'est le mal, je rajoute une entrée
>  qui pointe sur la même machine, et du coup ca devrait marcher de
> manière uniforme (intérieur et extérieur) puisque ipv6 (sans NAT) est, en
> principe, préféré par rapport à ipv4.
> 
> Et là, patatras, ca ne marche pas toujours (du genre ca dépend des
> moments). Je suspecte que l'algorithme "happy eyeballs" qui fait préférer
> la connexion la plus rapide, sélectionne ipv4 parfois.
> 
> Mon hypothèse vous parait-elle valable ?

Oui. Ça serait facile à valider avec un peu de Wireshark...

> comment héberger un truc derrière
> un machinbox et y accéder depuis chez soi sans se prendre la tête ?

Split DNS?

Enlever IPv4 du LAN et faire du NAT64? ;)

Simon


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

Re: [FRnOG] [TECH] Utilisez-vous la fonction proxy ARP ?

[Simon Perreault]

Le 2013-09-23 10:35, Michel Hostettler a écrit :
> Utilisez-vous encore la fonction proxy ARP aujourd'hui, dans vos réseaux LAN, 
> ou bien est-elle seulement un cas d'école ?
> 
> Si d'aventure vous aviez une raison de le faire, pourriez-vous SVP la 
> formuler ?

J'ai un cas d'usage un peu exotique. Schéma simplifié:

++A+-+B ++
|Internet|+|NAT46|--|Serveur IPv6|
++|+-+  ++
  |+--+
  +|Serveur dual-stack|
   +--+

Le lien A est dual-stack.
Le lien B est IPv6 seulement.

Je configure le NAT46 pour qu'il proxy-arpe l'adresse des serveurs IPv6
qui sont derrière lui. Le trafic IPv4 qui leur est destiné est donc
attiré vers le NAT46, où il est ensuite traduit en IPv6.

Simon


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

[FRnOG] Re: [TECH] RFC 7021: Assessing the Impact of Carrier-Grade NAT on Network Applications

[Simon Perreault]

Le 2013-09-20 11:22, Stephane Bortzmeyer a écrit :

Ils n'ont pas le pouvoir de migrer toutes les applications et tous
les fournisseurs de contenu à IPv6. Donc ils *doivent* continuer de
fournir de l'IPv4 à leurs clients.


Mais ils peuvent le faire par d'autres moyens. DS-Lite, par exemple,
qui est aussi du CGN mais qui a l'avantage de n'embêter que ceux qui
utilisent encore IPv4, en fournissant une porte de sortie aux autres,
à ceux qui ont migré vers IPv6.


Oui, mais ce n'est pas tous les ISPs peuvent migrer à DS-Lite. Les ISPs 
qui ne contrôlent pas le CPE ne peuvent pas dire à >90% de leurs clients 
de jeter leur CPE et d'en acheter un autre. DS-Lite n'est simplement pas 
une option pour eux.


Comme client, je préfèrerais qu'on me donne du dual-stack avec IPv6 
public et IPv4 NATé que du DS-Lite. Le problème, c'est quand il n'y a 
que de l'IPv4 NATé. Ça, c'est un peu décourageant.



...tout comme ils doivent payer pour porter leurs applications à
IPv6.


C'est souvent fait depuis longtemps mais, surtout, ce n'est pas _du
tout_ le même niveau de complexité du code.


Pour l'avoir fait plusieurs fois, ça varie du tout au tout selon 
l'application. Par exemple, le port d'Asterisk à IPv6 a été un tâche 
*énorme*. Alors que le port de FreeSWITCH (une application très 
semblable) a été fait en quelques jours sans maux de tête. Tout dépend 
de l'architecture.


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

Re: [FRnOG] [TECH] RFC 7021: Assessing the Impact of Carrier-Grade NAT on Network Applications

[Simon Perreault]

Bon, je ne peux pas m'empêcher de commencer le panel maintenant. :)

Le 2013-09-20 10:24, Stephane Bortzmeyer a écrit :

L'idée du CGN (un terme marketing, qu'il vaudrait mieux remplacer par
NAT 444 pour « deux NAT sur le trajet d'un paquet IPv4 »)


1. CGN est un terme qui a été voté en désespoir de cause par le 
working-group BEHAVE. Il y avait plusieurs belles propositions du genre 
Large-Scale NAT, Multi-User NAT, etc. Mais le fait était que CGN était 
déjà un terme populaire et bien compris, alors on l'a gardé. Le 
marketing a gagné.


2. CGN n'implique pas NAT444. Voir la définition ici:

http://tools.ietf.org/html/rfc6888#section-2

En particulier ce contre-exemple:

   Another possible topology is one for hotspots, where there is no
   customer premise or customer premises equipment (CPE), but where a
   CGN serves a bunch of customers who don't trust each other; hence,
   fairness is an issue.  One important difference with the previous
   topology is the absence of a second layer of NAT.  This, however, has
   no impact on CGN requirements since they are driven by fairness and
   robustness in the service provided to customers, which applies in
   both cases.


est de faire
beaucoup d'efforts et de dépenser beaucoup d'argent pour ne *pas*
migrer vers IPv6. Au lieu de déployer IPv6, ce qui simplifierait
beaucoup les choses, notamment pour les applications,


Les ISPs sont coincés (peut-être qu'ils ont une part de responsabilité). 
Ils n'ont pas le pouvoir de migrer toutes les applications et tous les 
fournisseurs de contenu à IPv6. Donc ils *doivent* continuer de fournir 
de l'IPv4 à leurs clients. La migration à IPv6 a peu de chose à voir 
avec ça. Un ISP ayant migré tous ses clients à IPv6 doit toujours leur 
fournir de l'IPv4. CGN est un moyen pour le faire.



Soyons optimistes, il y a eu des améliorations entre les tests de 2010
et ceux de 2011, notamment grâce à l'utilisation plus fréquente de STUN
ou de relais permettant de contourner les problèmes du NAT. Le RFC ne
parle pas de l'aspect économique mais je note que, lorsqu'on évalue le
coût des CGN, il faut voir que c'est aux auteurs d'application de payer
pour les FAI, en augmentant la complexité de leurs applications pour
contourner les obstacles.


...tout comme ils doivent payer pour porter leurs applications à IPv6.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

Re: [FRnOG] [TECH] IPv6: questions sur le routage et le dual wan

[Simon Perreault]

Le 2013-09-19 15:04, Sebastien DIEFENBRONN a écrit :
>> Le préfixe routé par le FAI = 2001:db8:fe8f::/48
>>
>> Le sous réseau d'interco OpenBSD/GW2 = 2001:db8:fe8f:1000::/64 (<= qui
>> est effectivement celui utilisé pour le NAT) .
> Dans ce cas, je vois deux solutions mais il y en a peut-être d'autres:
> - ND-Proxy
> - Prendre deux /64 différents pour l'interco et le NAT puis ajouter une
> statique sur GW2 avec l'OpenBSD en next-hop.

La deuxième option est la seule viable à mon avis. ND-Proxy, c'est un hack.

Simon


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

Re: [FRnOG] [TECH] IPv6: questions sur le routage et le dual wan

[Simon Perreault]

Le 2013-09-19 10:00, Sebastien DIEFENBRONN a écrit :
> Si wan2=2001:db8:fe8b:1000::/64, GW2 ne connait pas directement
> 2001:db8:fe8f:1000::/48, il te suffit donc d'avoir une statique,
> 2001:db8:fe8f::/48 next-hop OpenBSD, sur GW2. Comme l'a dit Simon, GW2
> n'aura qu'à faire qu'un ND pour le next-hop (ici OpenBSD) et non pour
> l'adresse de destination.

+1

Simon


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

Re: [FRnOG] [TECH] IPv6: questions sur le routage et le dual wan

[Simon Perreault]

Le 2013-09-18 20:57, Christophe a écrit :
> Bonsoir,
> 
> Le 18/09/2013 18:13, Simon Perreault a écrit :
>>
>> Le gateway en amont veut router un paquet destiné à
>> 2001:db8:fe8f:1000:+host. Pourquoi ne trouve-t-il pas 2001:db8:fe8f::/48
>> dans sa table de routage? Si ce /48 est bien dans sa table, il ne
>> devrait pas faire du ND pour l'adresse de destination, il devrait faire
>> du ND pour l'adresse du next hop. Et le next hop, c'est le routeur
>> OpenBSD.
>>
>> Imaginons qu'on élimine tout le NPTv6. Si le gateway en amont a un
>> paquet adressé à votre /48, il va faire quoi avec?
>>
> 
> Peut être manque t'il quelques infos dans ce cas.
> La situation est donc dans le détail la suivante :
> 
> lan <=> OPENBSD <=> wan2 <=> GW2 <=> interco2 <=> ISP2 <=> vaste internet.
> (Schéma identique : `echo $#|sed s/2/1/g` pour la connexion et route par
> défaut).
> 
> ISP2 nous connaît bien et route le 2001:db8:fe8f::/48 vers GW2 à travers
> interco2.
> 
> GW2 (que j'ai à quelques mètres de moi, et sur lequel j'ai la main :
> Cisco série 800) , n'a que deux réseaux directement connectés :
> 
> * interco2 : un /64 avec uniquement 2 adresses IPv6 utilisées.
> (2001:db8:fe00:150::/64)
> * wan2 : le fameux 2001:db8:fe8b:1000::/64
> 
> Et la seule route statique suivante :
> * ::/0 , "ouh ben ca, c'est ISP2".

Il manque 2001:db8:fe8f::/48 avec next-hop OPENBSD, non?

Simon


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

Re: [FRnOG] [TECH] IPv6: questions sur le routage et le dual wan

[Simon Perreault]

Le 2013-09-18 17:54, Christophe a écrit :
> Je vais essayer de faire simple ;) .

HA!

> vlan200 = wan1 => prefixe 2001:db8:feaf:1::/64 (issu d'un /48 public)
> vlan201 = wan2 => prefixe 2001:db8:fe8f:1000::/64 (issu d'un deuxième
> /48 public)
> 
> 
> vlan10 = lan => préfixe 2001:db8:feaf:1000::/64 (issu du préfixe /48 de
> wan1)
> 
> Donc adressage publique sur le LAN.
> 
> Route par défaut par une gateway sur le vlan200 .
> Comportement par défaut dans ces conditions = pas de NAT.
> 
> But étant par exemple : de router tout ce qui est Web (80 et 443) sur le
> wan2 , et de laisser le reste sur wan1.
> 
> Ce qui est en place à l'heure actuelle (fonctionnel mais un peu crade,
> et c'est pour cette raison que je cherche le moyen de faire mieux) :
> 
> v6_lan_net="2001:db8:feaf:1000::/64"
> v6_wan2_net="2001:db8:fe8f:1000::/64"
> 
> v6_wan2_nathttpout="2001:db8:fe8f:1000::80"
> # L'adresse précédente est aliasée sur l'interface vlan201
> 
> v6_host_gwnet2="fe80::9e4e:20ff:fe3a:858e"
> # gateway sur le vlan201 (celle qui figure dans la trace tcpdump du
> dernier mail)
> 
> table  { # ici , tout une liste de réseaux accessibles ,
> soit directement par le routeur, soit par un vpn }
> 
> Et au final, cela tient dans les deux lignes suivantes :
> 
> pass in quick on $int_if inet6 proto tcp from $v6_lan_net to !
>  port { 80,443 } route-to ($ext2_if $v6_host_gwnet2) tag
> webnav keep state
> 
> pass out on $ext2_if inet6 from $v6_lan_net to any nat-to
> $v6_host_nathttpout tagged webnav keep state
> 
> Tout sort donc par une seule et même IPv6.
> 
> 
> Le but serait donc de remplacer cela par :
> 
> (la même première ligne)
> et
> match on $ext2_if from $v6_lan_net binat-to $v6_wan2_net bitmask
> 
> 
> Ce qui en partie fonctionne, car les paquets arrivant du lan
> 2001:db8:feaf:1000:+host et sortant sur l'interface vlan201, sont bien
> translatés en 2001:db8:fe8f:1000:+host.
> 
> C'est au retour que ca coince ;) . La gateway à l'autre bout
> ($v6_host_gwnet2) tente savoir à qui appartient le packet translaté, et
> la , c'est le drame ;) .

???

Le gateway en amont veut router un paquet destiné à
2001:db8:fe8f:1000:+host. Pourquoi ne trouve-t-il pas 2001:db8:fe8f::/48
dans sa table de routage? Si ce /48 est bien dans sa table, il ne
devrait pas faire du ND pour l'adresse de destination, il devrait faire
du ND pour l'adresse du next hop. Et le next hop, c'est le routeur OpenBSD.

Imaginons qu'on élimine tout le NPTv6. Si le gateway en amont a un
paquet adressé à votre /48, il va faire quoi avec?

Simon


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

Re: [FRnOG] [TECH] IPv6: questions sur le routage et le dual wan

[Simon Perreault]

Le 2013-09-17 20:50, Christophe a écrit :
> fe80::9e4e:20ff:fe3a:858e > ff02::1:ffef:2510: icmp6: neighbor sol: who
> has 2a01:abcd:::dcad:beff:feef:2510 [class 0xe0]
> 
> Et la , le routeur n'est pas en mesure de répondre , vu qu'il n'a pas
> cette adresse IPv6 lui même.

Exact.

Et bien que la suggestion de faire du proxy ARP/ND puisse résoudre ton
problème dans l'immédiat, on ne devrait pas avoir besoin de proxy ARP/ND
dans l'immense majorité des cas.

Je trouve que ça ressemble plutôt à un mauvais numérotage de tes liens
WAN/LAN. Peux-tu nous expliquer un peu comment c'est numéroté?
C'est-à-dire le /64 sur le WAN, le préfixe IPv6 qui t'es délégué pour le
LAN (devrait être http://www.frnog.org/

Re: [FRnOG] [TECH] IPv6: questions sur le routage et le dual wan

[Simon Perreault]

Le 2013-09-17 15:34, Christophe a écrit :
> Je n'avais pas connaissance de ce mot-clé bitmask ...
> 
> C'est récent ?

Oui. C'est apparu dans OpenBSD 3.3, il n'y a que 10 ans. :)

Simon


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

Re: [FRnOG] [TECH] IPv6: questions sur le routage et le dual wan

[Simon Perreault]

Le 2013-09-17 14:23, Emmanuel Thierry a écrit :
> 
> Le 17 sept. 2013 à 14:21, Simon Perreault a écrit :
> 
>> Le 2013-09-17 14:15, Emmanuel Thierry a écrit :
>>> Normalement le NPTv6 est sensé swapper les adresses de manière à préserver 
>>> le checksum intact. Est-ce que l'implémentation d'OpenBSD le fait ?
>>
>> Le but de préserver le checksum intact est d'avoir une implémentation
>> plus rapide. C'est une optimisation pure et simple. OpenBSD n'exploite
>> pas cette possible optimisation: il va toujours recalculer le checksum,
>> même si on fait attention de choisir $pfx1/64 et $pfx2/64 de façon à ce
>> que le checksum ne change pas. Le fait est que la performance en
>> forwarding d'un routeur logiciel est limitée par l'I/O réseau, pas par
>> la puissance CPU dépensée pour recalculer des checksums. Implémenter
>> l'optimisation dans OpenBSD serait donc inutile et même nuisible si on
>> considère les coûts engendrés par la complexité additionnelle du code.
> 
> Le but à mon sens est également de n'avoir pas à toucher au protocole de 
> transport, notamment s'il est inconnu du routeur. Est-ce que je me trompe ?

Vrai, mais dans ce cas il n'y a rien à implémenter. Il suffit de choisir
$pfx1/64 et $pfx2/64 de façon à ce qu'ils aient un effet neutre sur le
checksum.

Simon


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

Re: [FRnOG] [TECH] IPv6: questions sur le routage et le dual wan

[Simon Perreault]

Le 2013-09-17 14:15, Emmanuel Thierry a écrit :
> Normalement le NPTv6 est sensé swapper les adresses de manière à préserver le 
> checksum intact. Est-ce que l'implémentation d'OpenBSD le fait ?

Le but de préserver le checksum intact est d'avoir une implémentation
plus rapide. C'est une optimisation pure et simple. OpenBSD n'exploite
pas cette possible optimisation: il va toujours recalculer le checksum,
même si on fait attention de choisir $pfx1/64 et $pfx2/64 de façon à ce
que le checksum ne change pas. Le fait est que la performance en
forwarding d'un routeur logiciel est limitée par l'I/O réseau, pas par
la puissance CPU dépensée pour recalculer des checksums. Implémenter
l'optimisation dans OpenBSD serait donc inutile et même nuisible si on
considère les coûts engendrés par la complexité additionnelle du code.

Simon


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

Re: [FRnOG] [TECH] IPv6: questions sur le routage et le dual wan

[Simon Perreault]

Le 2013-09-17 13:37, Rémi Laurent a écrit :
> Si j'ai bien compris le princi de NPTv6 je pense que ce genre de
> règle devrait faire l'affaire
> 
> match in on $if inet6 from any to $pfx1/64 rdr-to $pfx2/64 bitmask 
> match out on $if inet6 from any to $pfx2/64 nat-to $pfx1/64
> bitmask

Pas tout à fait. Le matching doit être inversé, et il manque l'option
"static-port" avec la règle nat-to pour éviter de NATer les ports.

match in on $if inet6 from any to $pfx1/64 rdr-to $pfx2/64 bitmask
match out on $if inet6 from $pfx2/64 to any nat-to $pfx1/64 bitmask
static-port

Ou plus simple, en utilisant binat-to et en éliminant les termes
redondants:

match on $if from $pfx2/64 binat-to $pfx1/64 bitmask

(static-port est implicite avec binat-to.)

Simon


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

Re: [FRnOG] [TECH] IPv6: questions sur le routage et le dual wan

[Simon Perreault]

Le 2013-09-16 22:57, Alexandre PIERRET a écrit :
> Je m’intéresse à l'IPv6 et après avoir fais quelques tests en labs, je me
> pose des questions:
> 
> 1/ Routage
> Bien qu'il soit possible de configurer les routes de ses équipements vers
> des ip "publiques" ou faisant parti du "scope global", j'ai l'impression
> que le best practice est d'envoyer son trafic à l’adresse "link local" du
> prochain routeur. Suis-je dans le vrai? car je n'arrive pas à trouver de
> documentation sur les best practice.

Une très bon survol des avantages/inconvénients ici:

https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-00#section-2.2

En général, les opérateurs préfèrent numéroter leurs liens point-à-point
avec des adresses globales. C'est d'ailleurs pourquoi ce draft a été
abandonné:

https://tools.ietf.org/html/draft-ietf-opsec-lla-only-03

> Si c'est le cas, étant donné que les adresses "link local" sont définies
> par les équipements eux même, comment se passe le changement d'un routeur?
> faut il, du coup, redéfinir toutes ses routes?
> 
> 2/ Dual WAN
> Comment ça se passe si on souhaite avoir 2 liaisons wan de deux opérateurs
> différents? Est-on obligé de demander un range PI, et s'annoncer en BGP? ou
> finalement, doit on revenir au bon vieux NAT des chaumières? ou y'a t'il
> simplement d'autres méthodes propres?

Pareil comme en IPv4, avec la différence que tu as l'option d'utiliser
NPTv6, qui est une version moins méchante du NAT que l'on connaît.

Simon


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

Re: [FRnOG] [TECH] 2960 connaitre utilisation trafic ipv4 et ipv6

[Simon Perreault]

Le 2013-09-09 22:53, Christophe Lucas a écrit :

Je pense que notre ami avait ce genre de howto dans la tête sur la manière de 
poser une question sur une ml ou forum lorsqu'il t'a répondu :

http://www.catb.org/esr/faqs/smart-questions.html#before


Exactement. J'ai failli poster le lien dans un deuxième courriel, mais 
je me suis retenu à deux mains le temps de laisser retomber la poussière.


Enfin, pour les archives: impossible de distinguer v4 vs v6 dans le 
trafic switché par une 2960. La 2960 n'exporte pas les compteurs SNMP 
nécessaires, et il n'y a pas de commande CLI équivalente.


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

Re: [FRnOG] [TECH] Question de vocabulaire

[Simon Perreault]

Le 2013-09-07 10:49, Emmanuel Halbwachs a écrit :

Michel Py (Sat 2013-09-07 01:26:21 -0700) :

C'est quoi le nom en Français pour "encryption" ?

{ Chiffrage | Chiffrement | Cryptage | Autre }


Traditionnellement, j'ai toujours entendu/lu « chiffrement ».
Mais il semblerait que « cryptage » soit admis :

 http://fr.wikipedia.org/wiki/Chiffrement#Terminologie


Idem du côté de l'Office québécois de la langue française:

http://granddictionnaire.com/ficheOqlf.aspx?Id_Fiche=8387607

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

Re: [FRnOG] [TECH] 2960 connaitre utilisation trafic ipv4 et ipv6

[Simon Perreault]

Le 2013-09-05 10:54, Antoine Durant a écrit :
> Je suis en train de me poser la question suivante concernant mes switchs 
> cisco 2960 :
>  
> - Est-il possible d'avoir une idée du trafic qui passe en IPV4 et en IPV6 ? 
> J'ai en tête d'essayer de me faire des graph afin d'avoir le trafic v4 et 
> v6...
>  
> Je n'ai pas encore cherché sur le switch (si une commande existe pour avoir 
> le trafic v4 et/ou v6) si je pouvais coder cela afin de me faire les 
> remontées d'infos...

Pas encore cherché?

Et moi qui croyais que l'algorithme était:

1. Chercher.
2. Chercher plus.
3. Chercher encore plus.
4. En désespoir de cause, demander à FRNOG.

J'ai une 2960, je me posais la question moi aussi, je viens de chercher
et j'ai trouvé la réponse.

Bonne chance.

Simon


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

Re: [FRnOG] [TECH]Retour d'expériences CGN 444 / NAT64

[Simon Perreault]

Le 2013-09-02 16:42, Raphael Mazelier a écrit :
> Le problème c'est qu'avec du CGN/LSN même en 444 tu as quand même besoin
> de plus de fonctionnalités :
> - batch logging (ou autre)
> - des fonctionnalités qui rendent le truc le plus transparent possible à
> tes clients, genre hair-pinning et l'EIP/EIM
> 
> Hors ça j'ai pas vraiment trouvé d'equivalent en opensource.

Même expérience ici.

Mais bon, le logging et le "NAT gentil", ça n'a pas la même importance
pour tout le monde.

Simon


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

Re: [FRnOG] [TECH]Retour d'expériences CGN 444 / NAT64

[Simon Perreault]

Le 2013-09-02 15:53, Grégoire Leroy a écrit :
> Nous sommes en train de tester plusieurs solutions de CGN444 et du NAT64
> à états. Pour l'instant, on a mis en place une solution en lab avec un
> ASR1001 qui fonctionne plutôt bien. Dans la mesure où est plus proche de
> quelques milliers de clients que du million, on se demande si une
> solution libre Linux/iptables, FreeBSD/IPFW ou OpenBSD/Packet Filter ne
> serait pas aussi efficace pour le CGN 444 (pour le NAT 64, les tests
> avec viagenie/iptables ne se sont pas révélés concluants).

À noter que notre implémentation NAT64 OpenBSD, qui fait maintenant
partie de la distro officielle, est *beaucoup* plus efficace que notre
implémentation Linux. Les deux implémentations ne partagent aucune ligne
de code. À tester indépendamment, donc.

Que ce soit en NAT44 ou en NAT64, OpenBSD devrait facilement supporter
"quelques milliers de clients" sur une bonne machine, tout dépendant du
trafic généré (en paquets par seconde). On peut aussi configurer une
paire en actif/passif avec partage d'état de NAT et VRRP, ou même de la
répartition de charge actif/actif. OpenBSD fait ça "out of the box",
sans avoir à ajouter quoi que ce soit à la distro de base. Et ce, avec
une config simple et lisible, et la réputation d'être l'OS le plus
sécuritaire au monde.

Simon


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

Re: [FRnOG] Re: [BIZ] OVH - incident de sécurité

[Simon Perreault]

Le 2013-07-23 14:13, Stephane Bortzmeyer a écrit :
>> Ne serait-il pas plus pertinent de passer à un algorithme tel que
>> scrypt
> 
> Qui, lui, est un algorithme de chiffrement, donc ne convient pas à cet
> usage (si on chiffre les mots de passe, une compromission de la clé et
> tout est fichu).

Salut Stéphane,

scrypt est un algo de hachage *et* un outil de chiffrement.

https://www.tarsnap.com/scrypt.html

Simon


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

[FRnOG] Re: [tech] l'ICANN veut mettre fin a WHOIS

[Simon Perreault]

Le 2013-06-27 12:00, Stephane Bortzmeyer a écrit :

désolé d'avoir détourné la discussion.


C'est un scandale ! Personne ne fait jamais cela sur Frnog !


Je suis poli, ma maman m'a bien élevé. ;)

Simon


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

[FRnOG] Re: [tech] l'ICANN veut mettre fin a WHOIS

[Simon Perreault]

Le 2013-06-27 11:53, Stephane Bortzmeyer a écrit :

Le remplacement du protocole WHOIS par un autre protocole n'implique
pas la centralisation.


Mais la discussion ne portait pas sur le protocole mais sur une
proposition particulière, ARDS, dont la principale caractéristique est
d'être centralisée.


Dans ce cas, désolé d'avoir détourné la discussion.

(Au moins j'aurai pu expliquer que ARDS != RDAP.)

Simon


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

[FRnOG] Re: [tech] l'ICANN veut mettre fin a WHOIS

[Simon Perreault]

Le 2013-06-27 11:49, Stephane Bortzmeyer a écrit :

Et même si tu passes plein d'heures à faire du beau code qui traite
toutes les exceptions


Ne pas réinventer la roue, c'est déjà fait :

http://search.cpan.org/dist/Net-DRI/


Ça prouve mon point. C'est une librairie hyper complexe qui n'arrive 
tout de même pas à atteindre 100% de succès et qui doit continuellement 
s'adapter pour suivre les évolutions du protocole.


Alors qu'en RDAP on peut faire un client en 5 lignes de JavaScript, on 
sait qu'il marchera dans 100% des cas, et que demain il marchera encore.


Simon


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

Re: [FRnOG] [tech] l'ICANN veut mettre fin a WHOIS

[Simon Perreault]

Le 2013-06-27 02:13, Jérôme Nicolle a écrit :

Justement, WHOIS est broken.


Ah ? Moi je troue que ça arche plutôt bien. Un peu lent, mais rien de
plus à en demander. Qu'est ce que tu lui reproche ?


Le format est sous-spécifié, ce qui rend très difficile d'automatiser un 
processus qui ferait une requête WHOIS et traiterait le contenu de la 
réponse. Et même si tu passes plein d'heures à faire du beau code qui 
traite toutes les exceptions (ça va commencer à ressembler à de 
l'intelligence artificielle), le format change un peu à tous les jours, 
selon les évolutions de chaque registre.


Simon


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

[FRnOG] Re: [tech] l'ICANN veut mettre fin a WHOIS

[Simon Perreault]

Le 2013-06-27 09:20, Stephane Bortzmeyer a écrit :

Justement, WHOIS est broken.


Ses inconvénients sont ses avantages. Par exemple, l'absence de format
de sortie normalisé est une bonne chose. Ce « semantic firewall » rend
plus difficile la récolte automatisée massive de données.


Un iota plus difficile oui, mais tout de même très facile. On peut faire 
un petit script Perl en une soirée qui permettra de récolter 99.9% des 
données correctement.


Le format sous-spécifié de WHOIS n'est donc pas une bonne protection 
contre la récolte automatisée. Il est par contre un véritable problème 
pour ceux qui tentent d'automatiser des processus légitimes.



Et puis, remplacer un protocole décentralisé par un centralisé est-il
une bonne chose ? C'est comme, je ne sais pas, prenons un exemple
idiot, au lieu qu'on ait plusieurs serveurs SMTP, comme si tout le
monde utilisait un service central espionné par PRISM ?


Le remplacement du protocole WHOIS par un autre protocole n'implique pas 
la centralisation. Il s'agit seulement d'échanger un protocole contre un 
autre.


La centralisation des données peut se faire peu importe le protocole 
d'accès aux données. Les deux concepts (protocole vs centralisation) 
sont orthogonaux.



Pour ceux qui ne suivent pas les travaux de l'IETF, le remplaçant
actuellement proposé pour whois (et qui, comme whois, est
décentralisé), se nomme RDAP et repose sur des techniques
buzzword-compliant (REST et JSON). Il est actuellement en "Working
Group Last Call".


WHOIS et RDAP ne sont ni centralisés, ni décentralisés. L'architecture 
sous-jacente, elle, peut être centralisée ou décentralisée. C'est le 
protocole qui est en WGLC, alors que l'architecture n'est pas standardisée.


Le groupe de travail discute actuellement du processus de bootstrapping 
pour RDAP, ce qui implique une certaine forme d'architecture. La 
discussion est encore très jeune. Deux drafts proposent des méthodes 
décentralisées:


https://tools.ietf.org/html/draft-blanchet-weirds-bootstrap
https://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-ianaregistries

Simon


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

Re: [FRnOG] [tech] l'ICANN veut mettre fin a WHOIS

[Simon Perreault]

Le 2013-06-26 07:27, Raphaël Jacquot a écrit :

l'article est la

http://www.computerworld.com.au/article/465895/icann_working_group_seeks_kill_whois/


Le titre est sensationnaliste. WHOIS ne mourra pas, du moins pas dès le 
début. Il sera gardé opérationnel en parallèle.



le formulaire pour donner votre avis ici:

http://www.icann.org/en/groups/other/gtld-directory-services/share-24jun13-en.htm

imho, ca fait partie des trucs pour lesquels "If it ain't broke, don't fix it"


Justement, WHOIS est broken. Fixons-le.

(Conservateurs, les opérateurs réseau? Non! Ils sont progressistes et 
ouverts au changement.)


Simon


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

Re: [FRnOG] [Misc] Le troll du vendredi par Michel

[Simon Perreault]

Le 2013-05-03 08:05, Guillaume Barrot a écrit :

Pour référence juste :
http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/

Je ne sais pas Stéphane en a parlé de ce draft, mais ça vaut le coup
d'oeil... a posteriori, LDP était quand même bien l'archétype du protocole
pensé uniquement pour IPv4.


Bah, laissons tomber LDPv6 et toute la merde MPLS du coup. Passons 
directement au segment routing.


http://fr.slideshare.net/getyourbuildon/segment-routing-ipv6-world-congress-2013

Thank god it's trolldi!

Simon


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

Re: [FRnOG] Re: [TECH] RFC 6888: Common requirements for Carrier Grade NATs (CGNs)

[Simon Perreault]

Le 2013-05-02 17:56, Pascal Rullier a écrit :

Pour un FAI, déployer IPv6 ne résout pas le problème. Un FAI qui a
déployé IPv6 à 100% devra quand même installer un CGN tant que la
portion de trafic en IPv4 justifie le coût du CGN. C'est un effort sur
deux fronts.


et une passerelle NAT64 ? réseau interne en ipv6 avec quelques ipv4 pour
aller tater les sites ipv4 only.


Oui bien sûr. CGN ou NAT64 ou DS-Lite ou MAP ou lw4o6 ou ..., c'est selon.

Simon


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

Re: [FRnOG] Re: [TECH] RFC 6888: Common requirements for Carrier Grade NATs (CGNs)

[Simon Perreault]

Le 2013-05-02 17:33, sxpert a écrit :

bref, il va bien falloir, qu'un jour, un des deux groupes arrête de
faire la mauvaise tête, et se décide.


Ça va venir. L'adoption d'IPv6 grimpe très rapidement:

http://www.google.fr/ipv6/statistics.html

Manifestement, il y en a pour qui déployer IPv6 est déjà avantageux. 
Plus ça se déploie, plus ça devient avantageux pour d'autres. Ce n'est 
qu'une question de temps.


Nos beaux CGNs tout neufs vont devenir désuets trop vite. ;)

Simon


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

Re: [FRnOG] Re: [TECH] RFC 6888: Common requirements for Carrier Grade NATs (CGNs)

[Simon Perreault]

Le 2013-05-02 17:05, Stephane Bortzmeyer a écrit :

une évolution logique pour étendre la durée de vie des v4 face a un
déploiement encore trop faible des v6...


Je soupçonne fortement qu'on aurait pu déployer IPv6 avec le quart des
efforts qu'on met à déployer des CGN et à corriger leurs problèmes.


Pour un FAI, déployer IPv6 ne résout pas le problème. Un FAI qui a 
déployé IPv6 à 100% devra quand même installer un CGN tant que la 
portion de trafic en IPv4 justifie le coût du CGN. C'est un effort sur 
deux fronts.


Simon


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

Re: [FRnOG] [TECH] RFC 6888: Common requirements for Carrier Grade NATs (CGNs)

[Simon Perreault]

Le 2013-05-01 20:42, Gunther Ozerito a écrit :

Par contre, la gestion des logs coté FAI va être joyeuse, et couter un
bras, voire une couille ou deux. Des solutions à la Splunk risquent d'avoir
le vent dans le dos (pour ceux qui veulent investir en bourse, hein). On
risque de voir pousser des DC complets juste pour stocker les logs, si on
suit à la lettre la loi en vigueur...


Il y a des solutions. Le CGN de Cisco alloue les ports 100% 
dynamiquement, comme un NAT traditionnel, et génère donc beaucoup de 
logs. Mais ceux d'autres vendeurs, dont Alcatel, Juniper et Huawei, 
allouent les ports en bloc, ce qui génère beaucoup moins de logs au prix 
d'une légère perte de taux d'utilisation des adresses IPv4 externes. Il 
y a aussi le "deterministic NAT" qui alloue les ports statiquement tout 
en conservant une plage d'allocation dynamique pour les débordements.


La section 5 de notre RFC porte sur ce sujet, mais a été fortement 
édulcorée à cause des gueguerres entre vendeurs.


Simon


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

Re: [FRnOG] [JOBS] Ingénieur (junior) de recherche en réseaux IP au Québec

[Simon Perreault]

Le 2013-03-08 18:05, Dominique BLEUS a écrit :

Cette offre n'est valable que pour des personnes de nationalité française,
des personnes vivant en France ou des francophones?


Idéalement de nationalité française, parce que ça simplifie beaucoup la 
partie administrative grâce aux accords entre le Québec et la France.


Mais si on avait un bon candidat des Îles Moukmouk, et que ce fût 
possible administrativement, on le prendrait.


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

[FRnOG] [JOBS] Ingénieur (junior) de recherche en réseaux IP au Québec

[Simon Perreault]

Cette offre s'adresse à des Français voulant travailler au Québec.

Viagénie est une firme de R&D en réseaux IP, basée dans la belle ville 
de Québec. Elle aide les fournisseurs de service Internet, les 
manufacturiers d'équipement réseaux, les agences spatiales et les 
entreprises dans la conception de nouveaux protocoles, l'implémentation 
logicielle sur des plateformes embarquées, le déploiement et 
l'implantation de de ces nouvelles technologies dans les réseaux. Elle 
est constituée d'une petite équipe d'ingénieurs séniors dans les 
technologies telles que IPv6, VoIP, réseaux dans l'espace, 
internationalisation.


Viagénie recherche des ingénieurs (junior ou sénior), pour un stage ou 
un emploi permanent, avec les qualificatifs suivants (le mieux c'est de 
tous les avoir, mais ce n'est pas nécessaire):

- Excellente compréhension des protocoles TCP/IP
- Programmation en C, C++, Python, XML, JSON
- Expérience en administration de systèmes Linux ou BSD
- Sens de l'innovation, du prototypage, mais aussi de la qualité
- Bonne capacité d'écriture en français et anglais
- Travail d'équipe

Disponibilité immédiate, rémunération et avantages supérieurs au marché.

Si intéressé, contactez i...@viagenie.ca et incluez votre CV.


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

Re: [FRnOG] [BIZ] Cave à Momo : serveurs Supermicro, Sun, HP d'occaze

[Simon Perreault]

Le 2013-03-06 08:45, Jérémy Martin a écrit :

Perso, j'suis bien content de voir ces annonces, et je trouve qu'elles
ont bien leur place sur BIZ.


+1


A ceux que ça dérange, filtre BIZ vers vos SPAM et le problème sera réglé.


+1


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

Re: [FRnOG] [TECH] firewall sur routeur Quagga ??

[Simon Perreault]

Le 2013-01-31 21:43, Julien Lollivier a écrit :

Simon Perreault  (31/01/2013 18:06) :

Il y a des distros où conntrack n'est pas un module et n'est pas
désactivable.

*tousse* Fedora *tousse*


Ça doit toucher certaines versions de la Fedora uniquement, parce que
sous toutes celles que j'ai sous la main, même des vieilleries (FC4 ..)
j'ai bien un nf_conntrack ou un ip_conntrack.


Après vérification sur un F16, je suis content de voir que ça a changé! :)

Sur F14 c'était compilé direct dans le kernel.

Simon


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

Re: [FRnOG] [TECH] firewall sur routeur Quagga ??

[Simon Perreault]

Le 2013-01-31 17:41, Radu-Adrian Feurdean a écrit :

Plus precisement :
rm -f `locate conntrack.ko`
sinon, le module risque d'etre charge automatiquement avec un simple
iptables -L


Il y a des distros où conntrack n'est pas un module et n'est pas 
désactivable.


*tousse* Fedora *tousse*

Simon


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

Re: [FRnOG] [TECH] firewall sur routeur Quagga ??

[Simon Perreault]

Le 2013-01-31 17:14, Antoine Durant a écrit :

Pour appronfondir et répondre aux questions :
Il sagit d'un routeur (pas route reflector) qui a deux transitaires.

Architecture 64 Bits
2Go de Ram DDR3-1066 Mhz
1 Intel xeon E5530 à 2.40Ghz (4 Core, 8 Mega de cache)
2 disques sata


Ça fait juste renforcer le consensus: pas de firewall sur un routeur. :)

Simon


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

Re: [FRnOG] [TECH] firewall sur routeur Quagga ??

[Simon Perreault]

Le 2013-01-31 16:22, Christophe Baegert a écrit :

Oui, peut-être... avec 3 téras de RAM pour la table de connexions !!! On
parle d'un routeur BGP là !!!


1. Il n'a pas été dit que le routeur BGP passait du trafic. Peut-être ne 
fait-il que du BGP (e.g. un route reflector).


2. Pas besoin de stocker *tous* les flux en mémoire pour bénéficier de 
l'accélération. Juste à spécifier une limite de mémoire raisonnable, et 
quand la limite est atteinte on élimine l'état le plus vieux. Et il faut 
permettre à tous les types de paquet de créer un état. La table d'état 
est alors utilisée comme une cache LRU.


Simon


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

Re: [FRnOG] [TECH] firewall sur routeur Quagga ??

[Simon Perreault]

Le 2013-01-31 15:44, Christophe Baegert a écrit :

Le 31/01/2013 15:41, Antoine Durant a écrit :

Donc en gros pas de firewall sur un routeur, mais quelle protection
est-il possible de mettre en place sans forcément plomber le serveur ?


Si, le firewall c'est bon sans le conntrack, mais c'est moins pratique,
forcément...


Faux.

Voir l'article fondateur de pf:


"The benchmarks show that the lower cost of state
table lookups compared to the high cost of rule set
evaluations justify creating state for performance
reasons. Stateful filtering not only improves the
quality of the filter decisions, it effectively improves
filtering performance."

Simon


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

Re: [FRnOG] [MISC] Carrier Grade NAT, nous y voilà

[Simon Perreault]

Le 2013-01-15 17:14, Frédéric GANDER a écrit :

quand tu as  plus de 2 millions de mec qui ont du v6 potentiellement à la 
maison et que tu fais 20gbit/s de v6
j'appel pas ca un succès foudroyant au niveau du contenu


Le "potentiellement" est suspect.

Simon


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

Re: [FRnOG] [MISC] Carrier Grade NAT, nous y voilà

[Simon Perreault]

Le 2013-01-15 17:08, Frédéric GANDER a écrit :

ba j'aitester.com (40% du parc avec ipv6 activé) et ba non ca grimpe pas des 
masses ;)

et le motif de certain sites web pour ne pas mettre plus de contenu v6 :
"oui mais les outils de géomarketing et de ciblage ne marche pas en v6"


Mon point ce n'est pas qu'il y a beaucoup de sites en v6.
Mon point c'est que les sites importants sont en v6.

Juste en considérant Google+Facebook+YouTube, ça peut faire une grande 
proportion du trafic d'un ISP.


Simon


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

Re: [FRnOG] [MISC] Carrier Grade NAT, nous y voilà

[Simon Perreault]

Le 2013-01-15 16:37, Guillaume Leclanche a écrit :

En mettant IPv6 à on, tu peux très bien te retrouver avec >50% de
ton trafic sur IPv6 du jour au lendemain.

Là tu prêches un convaincu je crois :)


Ouais, j'étais d'ailleurs très surpris de voir un @corp.free.fr dire 
qu'il n'y a pas de contenu IPv6!



Cela dit, pour un ISP, activer IPv6 c'est comme faire décoller un avion:
y'a toute une série de petites loupiotes qui doivent passer au vert
avant d'y aller. Et leur nombre dépend de la taille de l'ISP et du matos
utilisé. Une fois que tout est au vert, ce sont presque tous les clients
de l'ISP qui peuvent être activés, ou en tous cas par phases successives.


Exact.

Mais l'argument "il n'y a pas de contenu IPv6" ne tient plus la route 
depuis quelques temps déjà.



Le NAT pour IPv4 reste obligatoire pour fournir accès à l'internet IPv4
de toute façon, en cas de manque d'adresses dans les réserves d'IP
publiques de l'ISP.
Et ne pas croyez que ça fasse plaisir aux ISPs de déployer du CGNAT
plutôt que de se contenter d'IPv6...


Au moins, en déployant IPv6, ça peut te permettre d'acheter un plus 
petit CGN...


Simon


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

Re: [FRnOG] [MISC] Carrier Grade NAT, nous y voilà

[Simon Perreault]

Le 2013-01-15 16:20, Frédéric GANDER a écrit :

il n'y a pas de contenu ipv6


Google?
Facebook?
YouTube?
etc. etc. etc.

C'est pas du contenu ça?

En mettant IPv6 à on, tu peux très bien te retrouver avec >50% de ton 
trafic sur IPv6 du jour au lendemain.


Simon


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

Re: [FRnOG] [MISC] Carrier Grade NAT, nous y voilà

[Simon Perreault]

Le 2013-01-15 15:32, Jimmy Thrasibule a écrit :

Face à la pénurie des adresses IPv4, plutôt que de déployer de l'IPv6,
les opérateurs semblent décidés à mettre en place un gros NAT pour tout
le monde.


SVP expliquez-moi comment déployer IPv6 permettrait d'éviter de déployer 
un CGN.


Merci,
Simon


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

Re: [FRnOG] [MISC] se passer des box FAI : technique, juridique (Was : Mieux que l'HADOPI, Free !)

[Simon Perreault]

Le 2013-01-08 17:09, Francois Demeyer a écrit :

Il fut un temps où nous ne pouvions pas connecter nos propres téléphones sur le 
réseau des PTT...
tous les arguments d'alors ressemblaient furieusement a ceux avancés 
aujourd'hui..
Le broadband n'en est donc encore qu'a cette phase ;-)


Je constate l'inverse. Au Canada, aux USA et ailleurs, les ISPs sont 
généralement en train de migrer d'un modèle "bring your own" à un modèle 
où ils contrôlent entièrement le CPE. Et ils ne s'arrêtent pas au CPE: 
ils offrent de plus en plus de services pour pénétrer toujours plus 
profondément dans la maison.


Simon


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

Re: [TECH] [FRnOG] : retour d’expérience Cisco 2821

[Simon Perreault]

Le 2012-12-22 10:53, Xavier Beaudouin a écrit :

Par contre en routage static, je te conseille plus un FreeBSD qu'un
OpenBSD...


Pourquoi?


Si tu veux faire du BGP + OSPF, la OpenBSD est plus intégré que
FreeBSD + OpenBGPd (OpenOSPF) ou Quagga (avec des bugs relous qui ne
sont jamais intégrés malgrès mes patches)... surtout si tu prends des
FreeBSD récents...


Un autre avantage d'OpenBSD est que le pf dans FreeBSD est en retard 
d'environ 2 ans. Il y a plein de nouvelles features dans le pf d'OpenBSD.


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

Re: [TECH] [FRnOG] : retour d’expérience Cisco 2821

[Simon Perreault]

Le 2012-12-21 16:23, Christophe Lucas a écrit :

J'ai pas vraiment de retour, mais :
http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf

dit : 170,000 pps.


J'ai récemment remplacé un 2821 qui bloquait à ~4000 pps. Je n'ai jamais 
su exactement pourquoi. Il me semble que la config était très ordinaire. 
Pas de Netflow, quelques ACLs simples. Peut-être IPv6?


On l'a remplacé par un PC ordinaire qui roule OpenBSD. Ce fut comme 
arriver soudainement au 21e siècle. ;)


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

[Simon Perreault]

Le 2012-12-21 12:54, Thomas Mangin a écrit :

Il y a ici une solution qui va dans le bon sens et qui permet aux
utilisateurs et aux développeurs de prendre leurs responsabilités,
ce serait dommage que de telles propositions partent à la poubelle
parce que certains opérateurs se croient plus malins.
L'intelligence dans le réseau on ne peut pas dire que cela ait déjà
marché...


Je n'ai pas de boule de cristal, et je ne sais pas si LEDBAT sera
déployé massivement ou pas. Je pense que l'approche a du mérite.


LEDBAD est déjà massivement déployé:

http://www.utorrent.com/intl/fr/help/documentation/utp

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

[FRnOG] Re: [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

[Simon Perreault]

Le 2012-12-21 11:06, Stephane Bortzmeyer a écrit :

La question qui tue : qui ici est prêt à faire une réduction de tarifs
à ses clients pour des applications « gentilles », qui utiliseraient
cet algorithme LEDBAT pour ne pas charger le réseau ?


Es-tu sérieux?


À moitié. L'idée te semble ridicule ?


Quel serait l'incitatif pour l'ISP?

Comment intégrer ça dans les modèles de tarification actuels?

Techniquement, comment est-ce que l'ISP pourrait identifier les paquets 
utilisant LEDBAT?


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

[Simon Perreault]

Le 2012-12-20 09:42, Stephane Bortzmeyer a écrit :

La question qui tue : qui ici est prêt à faire une réduction de tarifs
à ses clients pour des applications « gentilles », qui utiliseraient
cet algorithme LEDBAT pour ne pas charger le réseau ?


Stéphane,

Es-tu sérieux?

Cordialement,
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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