Re: [MISC] Re: [FRnOG] [JOBS] Ingénieurs et Consultants Réseaux (Avant-vente et Déploiement/Prestation)
La seule différence entre deux boîtes, c'est le salaire, et à la marge si les salaires sont comparables, les contraintes. Les modes d'organisation aussi, l'ambiance dans l'équipe, un subset de valeur commune avec l'objectif de la boîte. Le choix d'un travail est nécessairement la combinaison de plusieurs facteurs tel que le salaire, le temps de travail, l’intérêt du poste, la localisation, l'ambiance de travail, les avantages (télétravail, CE, etc...), le projet d'entreprise, etc... Chacun je pense possède sa propre équation pour déterminer si tel ou tel poste est intéressant et viable pour lui. Aujourd'hui nous avons la chance de pouvoir choisir dans notre branche un travail/entreprise qui correspond à notre équation personnelle. Ce n'est pas le cas de tout le monde loin s'en faut, alors profitons en. Personnellement je n'ai jamais mis le facteur salaire en 1er. J'ai certes un seuil minimal et une cohérence à avoir, mais d'autres facteurs sont tout aussi importants, voir plus. (j'ai parfois fait des gap négatif par exemple) Mon raisonnement est que ce qui me manque le plus c'est le temps. Hors donc on consacre tous beaucoup de temps à notre job. Il faut donc que je trouve du sens/plaisir à ce que je fais, sinon je change. Et cela est principalement lié au projet/organisation de la société, et la place que j'y prends. Le sentiment d’être vaguement utile, de construite un minimum, et d'en retirer quelque chose (autre que de l'argent). Mais ça c'est parce que nous avons tous de la chance dans notre secteur de pouvoir faire ce choix. -- Raphael Mazelier --- 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)
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é. Je suis je crois assez en accord avec la vision de Fred, ce qui n'est pas très étonnant vu que c'est en général le cas :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Supervision réseau
On 07/06/2017 17:41, Jean-Henri Antunes wrote: Bonjour a tous, ayant débuté sur Nagios, What's UP Gold et un outil maison on a testé un peu d'autre trucs, Zabbix, Centreon, shinken, puis on est resté sur Check_mk. Check Mk se pose comme bonne alternative... a essayer y a du graph de l'alerting, on peu y adjoindre nagvis pour des cartes etc... Oui alors attention check_mk c'est plus un ensemble d'outils qui gravitent autour de nagios plus qu'une solution complète à mon sens. On doit toujours utiliser un core nagios like (nagios, naemon, icinga, shinken, ou meme le core light proposé) pour lancer les checks générés par l'auto discover check_mk. Ceci étant check_mk (que je vois comme un framework de check pour nagios like) est extrêmement intéressant. Je l'ai longtemps utilisé avec succès et plaisir. Livestatus est aussi quasi indispensable à toute gui au dessus de nagios (ou l'alternative dans icinga2). Je suis beaucoup moins convaincu par la gui mulisites. En revanche pour tout ce qui est graphing je ne me passerai plus de grafana (et donc d'une vraie base tsdb graphites, influxdb ou mieux prometheus). Cela demande certes des agents ou exporters divers, un peu de temps de setup mais après c'est un bonheur. Ça c'était pour la partie monitoring/graphing infra/métier quand on a du temps. Pour surveiller rapidement un réseau Obersvium ou LibreNMS font bien le taff, malgré tout le mal que j'en pense. Attention à ne pas avoir des switchs trop sensible aux requêtes snmp (toute série de switchs en deux lettres d'un constructeur commençant par J au pif). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident
On 12/06/2017 18:40, DELMAS JACQUES wrote: Bonjour, En effet notre souhait est de pouvoir rejouer l'intégralité des emails même ceux délivrés afin de pallier le manque de solidité d'une infra. Aujourd'hui nous gardons les emails pendant 4 jours si le serveur ne répond pas mais notre objectif est d'être capable de rejouer les emails lorsque la boite destination a été pleine ou que le serveur renvoyait un rejet de l'email (blacklist du serveur d'émission, faux positif en spam ou en virus ou autre problème de ce type). Conserver les emais reçus je comprends, mais tenter de conserver les emails non délivrés c'est assez étrange. Pour les cas d'erreurs temporaires tu peux augmenter le temps de retries et sécuriser ton infra. Pour les erreurs définitives l'expéditeur doit recevoir un bounce. De toutes manières il doit avoir son mail dans sa boite "Sent" ? Certains emails ne peuvent pas ou ne doivent pas être perdus ... Mauvais usage des mails à mon humble avis, et/ou mauvaises éducations des utilisateurs. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Problème EQUNIX GIX Paris
On 15/06/2017 19:57, footp...@gmail.com wrote: Bonjour, Mh, mais ces gens là ont bien des sessions BGP avec des routes connected non ? Et du coup du traffic sourcé par leur port, au moins des ACK ? Lis le document. C'est très bien expliqué même si difficile à comprendre de prime abord. Le problème peut arriver si un peer A envoi du trafic à un autre peer B sans que A et B aient de sessions BGP (ils peerent juste avec les RS sinon en effet il y aurait un peu de traf BGP bi-directionnel) et que B utilise un autre path. Si A a un table ARP avec un timer un peu long (genre 4h) il connaît la mac de B pendant ce temps, pas la peine de faire de une requête ARP. Si le switch a un timer de mac-address-table inférieur (et c'est souvent le cas), pendant le delta, le switch n'a pas le choix et doit flooder. Comme personne ne lui répond il n'a aucun moyen de savoir comment associer la bonne mac au bon port. De la nécessité de mettre des pingers sur les IX (ce qui est peut être le cas je dis pas, c'est peu être autre chose). L'unknown unicast toujours un plaisir. (hein jph) J'ai eu des archis L2 bien flat ou j'avais jusqu'à 1Gbps ce qui m'a un peu obligé à revoir mes timers :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Recherche service DNS avec API
On 19/06/2017 16:31, Michel 'ic' Luczak wrote: Regards dnsmadeeasy. Je l’utilise depuis longtemps, même si la tarification a évolué défavorablement récemment. ++ ic Beaucoup d'acteurs, on peut citer bien sur route53 d'AWS (qui a des tarifs que je trouve étrangement correct). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Free et les soldes Steam
On 25/06/2017 00:34, Kavé Salamatian wrote: C’est un jeu non-coopératif que se font Free… Contents vs eyeball(s) version Free. Aka Free ne veut vraiment rien payer (bon ça à la limite) mais surtout veut faire payer (et cher) l'accès à ses précieux abonnés. Le truc c'est que cela commence à se voir, d'avoir en gros un seul transit saturé et des pni saturés (parce que les conditions d'upgrade sont souvent délirantes). Chacun sa guerre, mais de plus en plus de contents give up, et préfère ne rien faire et signifier à leur utilisateur que leur FAI ne joue pas le jeu. Et je les comprends. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Bonding Linux et Cisco LACP
On 26/06/2017 19:49, Youssef Ghorbal wrote: - Est ce que la spec (802.3ax ?) impose le fait que tt les packets d'une meme session TCP partent sur le meme lien physique ? Je ne trouve rien de clairement explicite. Je vois quelque chose concernant l'algo de hash qui doit respecter l'order des packets mais rien de plus. Le 802.3ad opére théoriquement au niveau 2. On lourait donc dire que peu importe le lien physique qu'emprunte une session tcp, tant que les paquets arrivent dans l'ordre. Ceci étant vu les algos de hash courants (couple src/dst @mac, ou @ip) de fait une sessions tcp emprunte toujours le même lien (sauf algo de hash type rr, ou adaptative). - Dans l'autre sens, est ce que les stacks reseaux (kernel, drivers, etc) s'attendent a voir atterir les packets TCP d'une meme session sur le meme port physique ?! Comment c'est sens se comporter si ce n'est pas le cas ? Si l'on prend l'exemple linux tout arrive sur une interface "bond" niveau l2. Le kernel devrait pouvoir s'en sortir dans tous les cas. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] optique DWDM pour une Lambda inter DC de Lambda Paris
On 05/07/2017 18:28, Souhayel BELHAJ wrote: Bonjour, Solid-Optics ça fonctionne plutôt bien. Yep solid-optics, pure-optics, ou du skylane (via infractive par ex). J'ai eu des soucis en revanche avec un site chinois en deux lettres. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] optique DWDM pour une Lambda inter DC de Lambda Paris
On 05/07/2017 22:07, Michel Py wrote: Tu pourrais préciser quel genre de soucis ? J'ai pas encore acheté du DWDM chez eux mais je m'approvisionne régulièrement pour les optiques grises et les cables. Sur du consommable (du gris et du DAC) pas énormément de soucis, un taux de panne raisonnable. Sur du *wdm en revanche un festival, mauvais codage, mauvaise longueur d'onde, sensibilité en rx foireuse, etc... j'en passe et des meilleures. Ceci étant ils m'ont toujours repris les optiques, mais le temps passé en debug, allez-retour au DC, en colis vers la chine et en discussion avec le support n'a pas compensé le meilleur prix initial. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Gérer le cas d'une rupture de liaison entre deux routeurs d'un même AS
Quelle est la façon "propre" de faire cela ? Cad d'avoir deux sites avec leur propres transit, habituellement connectés mais qui puissent se comporter comme deux iles le temps que l'on répare ? Comme l'a justement dit Guillaume ce cas ne doit pas arriver. Ton ibgp ne doit pas casser. Soit tu prend deux AS distincts/indépendants et qui donc peuvent vivre leurs vies (et cela peut faire sens), soit tu redondes tes liens correctement. Évidement le soucis c'est que tu n'as pas les même @IP des deux cotés, (c'est plutôt sain comme pratique pour la redondance), mais je conçois que cela peux poser problème. (a part si tu veux anycaster certain services mais c'est un autre sujet). Après si tu veux conserver un seul AS et que tu n'as pas de vrai budget fibres tu peux tenter des trucs étranges/sales : Tu peux par exemple annoncer ton superblock des deux cotés et choisir un sous block par site, originate que du site en question en ebgp et ibgp, de sorte qu'en cas de split brain chaque site n'annonce que le superblock et son sous-block. Et tu retombe dans le cas ou tu dédie des plages spécifiques à chaque site, donc autant les rendre complètement indépendants et demander un 2eme ASn. Les vrais questions que tu dois te poser en tout cas : à quoi sert ton multi-site actuel ? full redondance ? aucune dépendance entre les sites ? n'as tu vraiment pas de budget pour une lambda ou dark ? (parce que c'est franchement peu cher en RP). PS : tu peux aussi en effet faire du backup sur GRE (j'ai déjà fait en désespoir de cause entre paris et nyc *fear*) mais c'était vraiment un palliatif temporaire. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Questions Nexus 3000
On 06/07/2017 21:23, Michel Py wrote: C'est pas un peu usine à gaz sur les bords pour remplacer deux commandes qui marchaient depuis la nuit des temps en IOS et que Cisco a pas jugé bon d'implémenter en NXOS ? VTP sérieusement ? je n'envisage même pas que l'on puisse utiliser cela en prod; cela c'est toujours terminé en désastre par chez moi. Non franchement l'automatisation des équipements réseaux ce n'est plus optionnel. En revanche ce qui est plus discutable c'est l'implémentation. Sur les différentes gamme de nexus c'est assez disparate. (pour ne pas dire plus). Arista, Juniper et autre nouveau NOS sont bien plus avancé sur le sujet. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Questions Nexus 3000
On 08/07/2017 05:42, Michel Py wrote: Ben justement je suis "enterprise" maintenant et sur le réseau de prod principal (on en a plusieurs petits ou c'est physiquement séparé pas, dans la même salle, et toussa) qui est à ce jour 100% Catalyst çà me fait bien chier de devoir mettre encore une autre usine à gaz parce que sur certains Nexus, Cisco a désactivé VTP client. Encore une niaiserie de leur marketing à la con. Les enfants, le réseau çà existait avant l'Internet et il reste encore quelques vieux cons qui se rappellent ce que c'était avant. Je me rappelle de mon premier commutateur, avant que Cisco ne l'appelle Catalyst : c'était un Grand Junction, çà coutait la peau du c.., on pouvait avoir que 1 MAC adresse par port 10 mégas sauf pour LE port 100 mégas, et il y avait pas VTP. On tous commencé avant internet je te rassure, ça n’empêche pas de vivre avec son temps, surtout quand les nouvelles options proposées sont plus malines. Si tu es full cisco il y a plein d'autre options pour du campus. Si il n'y avait pas VTP, EIGRP, VPST, ISL, HSRP, et autres "merdes propriétaires" inventées par Cisco je me demande bien qui aurait inventé dot1q, VRRP, et autres. Alors la c'est extrêmement discutable. Il est indéniable que Cisco a été vecteur d'innovation dans le réseau. Mais s'il n'avait pas été la quelqu'un l'autre fait différemment et on aurait peut être des protocoles mieux foutu ? Dans bien des cas on a normalisé un protocole propriétaire cisco quasi à l'identique. Bien ou pas ? -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Questions Nexus 3000
On 09/07/2017 02:54, Guillaume Barrot wrote: Ouais enfin n'oublions pas que SpanningTree, ISIS ... tout ça c'est DEC. Le FC, Brocade. Etc. On a dit la même chose je crois. Mon point était de dire qu'on a souvent copier des protocoles propriétaires Cisco (ou autres) pour les normaliser, plus par facilité qu'autre chose. Cisco et les autres poussent leurs propres technologies/protocoles plus dans une logique de locking des utilisateurs que dans une vraie réflexion de fond sur les besoins du réseau de nos jours. Malheureusement pour eux l'opensource comme ailleurs va gagner. Ça prendra juste un peu plus de temps qu'ailleurs mais c'est inéluctable. Et peut être que ces sociétés vont comprendre qu'elles devraient se recentrer sur ce qu'elles font bien : du hard high-end et de l'intégration. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] UCARP/VRRP avec Debian problème
On 07/07/2017 19:33, David Ponzone wrote: Je sais pas si c’est encore d’actualité, mais en cherchant vite fait pour aider Sébastien, j’ai trouvé ça concernant uCARP: http://www.syawar.com/2013/01/16/ucarp-prevent-re-assertion-of-original-master/ <http://www.syawar.com/2013/01/16/ucarp-prevent-re-assertion-of-original-master/> A priori, le monsieur a aussi eu besoin de déclarer les 2 en SLAVE pour que ça tombe en marche, avec un inconvénient. Cela vaut ce que vaut comme retour, mais j'avais eu exactement le meme genre de soucis quand j'avais évaluer ucarp à l'époque. Après avoir lu le code source en partie j'avais conclu sur le fait que cela ne faisait pas ce qui était annoncé. Étonnant pour un truc codé par Franck Denis mais bref j'étais passé sur keepalived. (et pourtant j'étais fan du truc, simple et efficace sur le papier). Sinon s'il y a des gens aventureux ils peuvent tester mon essai d'un démon de HA : https://github.com/ut0mt8/simple-ha-go ; ça marchait pour moi :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Avis sur switch juniper ex3300
On 13/07/2017 11:51, Jean-Baptiste COUPIAC wrote: On utilise des EX3300 depuis quelques années à présent. Aucun soucis, fiable, et surtout JunOS , avec son commit confirmed. Niveau prix, un EX3300 en 48T, c'est moins de 1400€, donc plutôt bon marché J'ai déjà eu l'occasion de le dire mais dans Job-1 on était utilisateur massif des ex3300 dans des configurations variés (du switch standalone, au VCs de 8 membres avec multiples ajouts/reconf). Globalement le rapport qualité prix est excellent. Je mentirais si je disais que dans le tas on a pas eu des soucis; mais j'en reprendrais sans hésiter (je ne dirais pas ça de toute la gamme EX, les nouveaux n'étant toujours pas sec) Un des soucis agaçant reste le snmp qui peut bouffer tout le cpu de la RE surtout sur les gros VCs. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Optimisation bgp avec 2 transits
On 15/07/2017 11:44, Antoine DURANT wrote: Comment feriez vous dans cette configuration ? Relire l'algorithme de path selection de bgp. http://packetlife.net/media/library/1/BGP.pdf par exemple (parce que packetlife fait de beaux cheatsheets) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Forage à PA3
On 25/07/2017 17:02, Hugues VOITURIER wrote: À mon avis ils veulent nous faire une Online et construire un abri anti atomique sous le DC :D Ou plus probablement ils sont à la recherche de quelques fibres qu'ils ont égarés ;) Perso si j'étais encore à PA3 je serais pas plus rassuré que ça... -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Souci de configuration d’IP de management sur un chassis virtuel d’EX2200
Bonsoir,
Ce que tu souhaites faire n'est pas possible à ma connaissance.
L'option master-only n'est à priori pas compatible avec le
virtual-chassis des EX. Elle fonctionne sur du cluster SRX, ou du MX
avec dual-RE.
Sur EX tu peux avoir une @IP flottante entre tous les membres de ton VC
via l'interface vme. Elle regroupe toutes les me du VC et ne répond que
sur le switch qui est master (et donc possède la RE-master).
Tu ne peux pas mixer vme et me ; aka mettre une @IP sur vme.0 et une
autre @IP sur me.0.
Tu peux en revanche configurer une @IP différente par membre de switch
sur chaque me0. Voir la KB15556. Ceci étant de souvenir tu arriveras
quoi qu'il arrive sur la RE-master. Ce qui n'est pas illogique car
Juniper considère que tant que le VC est consistant tu as une seule
entité à manager.
Ceci étant dit mon proTIPS du jour => Ne pas utiliser ces maudites
interfaces de management.
Utilise une @IP dans un vlan inband pour le management courant, et paye
toi le (non)-luxe de câbler tes ports serial sur un switch console, lui
même connecté sur un réseau OOB en cas de gros crash.
Cela t'évitera quelques incidents sympas (j'ai expérimenté et bien
d'autres aussi). Ou si tu tiens vraiment à utiliser ces interfaces prend
bien garde à les brancher sur un réseau très maîtrisé ; une interface L3
par exemple :)
Je suis assez critique de Juniper (mais les autres ne font guère mieux)
sur ce point. Le design des ces interfaces (me, fxp0 ou autre) a
toujours été broken. Il serait bien plus intéressant d'avoir un vrai
module de management indépendant de l’équipement réseau (ala ILO/Drac
par exemple).
--
Raphael Mazelier
On 07/08/2017 17:14, Alarig Le Lay wrote:
Bonjour,
J’ai un VC avec deux EX2200 en JunOS 15.1R5.5 : sw-junip-ex2200-01 et
sw-junip-ex2200-02
Mon but est d’avoir une IP par EX pour accéder à chaque membre même en cas de
coupure du lien de VC et une IP globale pour administrer le cluster.
Le plan est très simple :
172.16.0.1/24 sw-junip-ex2200-01
172.16.0.2/24 sw-junip-ex2200-02
172.16.0.3/24 cluster
Pour configurer les IPs de chaque membre, j’ai utilisé les groupes :
alarig@sw-junip-ex2200-01# show groups
member0 {
when {
member member0;
}
interfaces {
me0 {
unit 22 {
family inet {
address 172.16.0.1/24;
}
}
}
}
}
member1 {
when {
member member1;
}
interfaces {
me0 {
unit 22 {
family inet {
address 172.16.0.2/24;
}
}
}
}
}
alarig@sw-junip-ex2200-01# show apply-groups
apply-groups [ member1 member0 ];
Et pour l’IP de management du cluster, je l’ai mise en master-only directement
sur l’interface :
alarig@sw-junip-ex2200-01# show interfaces me0
vlan-tagging;
unit 0 {
vlan-id 0;
family inet;
}
unit 22 {
vlan-id 22;
family inet {
address 172.16.0.3/24 {
master-only;
}
}
}
Mes IPs dans la configuration 'groups' sont bien prises en compte car cela se
voit si je | display inheritance :
alarig@sw-junip-ex2200-01# show interfaces me0 | display inheritance
vlan-tagging;
unit 0 {
vlan-id 0;
family inet;
}
unit 22 {
vlan-id 22;
family inet {
address 172.16.0.3/24 {
master-only;
}
##
## '172.16.0.1/24' was inherited from group 'member0'
##
address 172.16.0.1/24;
}
}
Seulement, avec cette configuration je n’ai que 172.16.0.1 qui répond.
Savez-vous d’où cela peut venir ?
Merci pour vos conseils,
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] Ping depuis ibgp/ospf quagga
On 11/08/2017 14:10, Antoine DURANT wrote: Le préfixe A.A.A.A/24 est directement connecté à quagga2 via son upstream. Depuis quagga2 je peux effectivement pinguer A.A.A.A Quand tu dis directement connecté, tu veux dire que c'est vraiment un subnet rattaché à une interface de ton quagga2 ? Depuis qagga1 qui ne connait pas A.A.A.A/24 via son upstream il le connait via ibgp/ospf. Question si c'est le cas, ce subnet connected est redistribué uniquement dans ibgp (ou dans ospf aussi ? visiblement ibgp) A.A.A.0/24 est physiquement dans la table de routage de quagga1 mais il ne peut pas pinguer A.A.A.A même en utilisant la dummy du ibgp. tcpdump est ton ami. Avec quelle @IP source/dest le paquet icmp de A => B arrive sur B et comment il ressort sur B et arrive sur A (ou pas d'ailleurs). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RRDTool graph trafic interface vlan CISCO
On 22/08/2017 10:13, Philippe Bourcier wrote: Certes, mais mon mail a aussi un rôle didactique, car encore beaucoup de gens ne connaissent pas les TSDB, donc "font comme on a toujours fait", plus par ignorance du fait qu'il y ait beaucoup mieux de nos jours que par volonté de s'auto-mutiler (Ouh, j'ai été très vilaine, je vais faire du RRD ! ;) )... En effet de nos jours il est quand même plus simple et sexy de stocker ses métriques réseaux dans une tsdb (influxdb, ou ma préférence actuelle prometheus) et utiliser grafana pour avoir de jolis graphs dynamiques. Ceci étant il y a un use-case qui m'avait encore forcé à faire du rrd à l'époque (il y a 3/4 ans) : la génération des graphs de billing monthly au 95th. Il y avait plusieurs problèmes : - génération d'une image png (ok on peut faire du phantomjs mais le rendu est méga moche) - calcul et affichage même du 95th (avec grafana et influx à l’époque j'avais galéré, je crois que l'on peut s'en sortir avec des continuous query mais bon). Bref il m'avait semblé plus simple de faire un pov script pour render un png avec rrd. J'imagine que depuis il existe des solutions et je suis preneur de les connaître :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] AS number
Je n'ai qu'un transitaire, mais sur 2 pops. Un pop est relié avec un AS et l'autre avec un autre AS, c'est historique. Aujourd'hui je veux fermer un des pops et donc ramener mon ancien AS sur le pop restant. Je vais poser la question à mon transitaire pour une deuxième session sur ce pop. la mise à jour du RIPE c'est pas long mais n'étend pas super à l'aise avec je préfère voir les autres solutions avant. Tu as plusieurs options : - tu garde un seul AS et tu annonces tous tes préfixes via cet AS à ton transit (le plus simple / propre). OK il faut que tu demandes à ton transit d'accepter ce trafic, et d'updater RIPE. (5min) - tu décide de garder deux AS, donc dans ce cas ton ancien AS va transiter par ton autre AS. Même dans ce cas tu dois prévenir ton transit et update la RIPE DB. - tu bricole et tu demande deux sessions à ton transitaire, ce qu'il devrait accepter ou pas fonction de sa flexibilité (deux vlans ?, un autre lien ?) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HPE / Comware 7 - API REST
On 06/09/2017 00:19, Clément Guivy wrote: Bonjour, Sur les versions récentes de Comware 7, un accès via API REST a été ajouté en tant que nouvelle fonctionnalité. Par contre je ne trouve pas de documentation là-dessus au delà des commandes à passer sur le switch pour l'activer. Quelqu'un a t-il des exemples d'utilisation de l'API ou tout simplement un lien vers la documentation ? Je ne trouve rien sur le site d'HPE. merci. Si quelqu'un a, ou connaît bien comware je suis preneur aussi d'exemple d'automatisation (on ne choisit pas toujours son matos réseaux, même si cela fonctionne étonnement bien). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering Nerim ?
On 07/09/2017 17:00, David Ponzone wrote: peer...@nerim.net non ? Ca répond pas ? Antoine ? :) La vox populli sera t'elle entendue ? (ok elle était facile) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [FRNOG][JOBS] eTF1 recrute
Salut à tous, et désolé pour le cross-post. (je sais on est sur une liste réseaux/opérateurs mais comme beaucoup de monde lit la liste). Afin de nous accompagner dans notre (re)-volution nous cherchons des gens motivés qui souhaitent rejoindre une boite où ça bouge pas mal. Dans mon équipe en particulier je recherche toujours des sysadmins/devops/netops (peu importe comment vous vous définissez) capables de nous aider à la transformation de notre infrastructure et éradiquer le legacy. Les keywords techniques sont : linux, opensource, web, scaling, cloud, ci, container, micro-services, k8s, video, automatisation, go, stockage objet, own-cdn, etc, etc... Nous avons déjà une belle archi mais on peut et doit encore faire mieux! Le mindset : techy, openmind, teamplayer/(cooperation dev/ops), convivial (bref l'inverse du BOFH). Le profil idéal n'existant pas j’étudie tout, même si je souhaite plutôt des personnes ayant déjà une expérience de la prod. Nous sommes situés dans la tour TF1 (Boulogne Billancourt). Le salaire dépendra de l'xp (une fourchette très large 40<>60K pour le salaire+package/intéressement). Donc si cela vous parle ou que vous connaissez des personnes que c'est susceptibles d’intéresser n'hésitez surtout pas à me contacter. PS : eTF1 ce sont les personnes qui fabriquent le site myTF1 and co, et qui diffusent la vidéo de qualité des chaînes du groupe (beaucoup). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [FRNOG][JOBS] eTF1 recrute
On 11/09/2017 18:00, Guillaume Barrot wrote: "Nous sommes situés dans la tour TF1 (Boulogne Billancourt)." Vous prenez toujours pas en télétravail ? (Le sens de la phrase donne à penser que non, en fait, mais si jamais, profites en pour me dire que j'ai tord, y a plein de gens qui seront intéressés) Va falloir vous y mettre rapidement :) https://www.lesechos.fr/economie-france/social/010218932431-teletravail-ce-que-les-ordonnances-vont-changer-2112874.php Je suis personnellement convaincu, et c'est le sens de l'histoire. Des accords sont en train d’être négociés mais cela prend du temps, car pour les grosses société le télétravail impose un nouveau cadre et contre-parties pour les salariés. Ceci dit je vous rassure le télétravail informel est déjà largement répandu. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [MISC] RE: [FRnOG] [MICS] eTF1 recrute
On 12/09/2017 09:59, Xavier ROCA wrote: Par contre l'appli Mobile ou Web du replay offre une très mauvaise expèreice utilisateur. Je suis preneur de tout retour la dessus. On fait un énorme effort la dessus car après tout c'est notre buisness qui est basé sur l'expérience utilisateur. Perdre des utilisateurs à cause de problème d'ui ou autre plantage c'est autant de CA en moins. Avant de me lancer ici sur ce sujet, j'ai pris le emps de sondé mon entourage et mes collègues de bureaux qui ont en plus, une notion métier sur ce sujet. Il est ou le problème, notamment en exemple le lancement des pubs qui plante plus que très régulièrement. Au point où l'on préfére visualiser le contenu de TF1 mais via d'autres interfaçe... maintenant moi aussi. Tes collègues du métier ont du t'expliquer les problèmes de travailler avec les régies pub tierces. Nous n'avons qu'un contrôle assez limité sur les Adservers. Et une pub ou une campagne foireuse se traduit malheureusement parfois par un plantage du player ou de l'application. (On a beau essayé de mettre toutes les sécurités possibles, quand on nous envoie un réponse daubé ou un timeout c'est peu assez facile à catcher de manière transparente pour l'utilisateur) Le reste de la problématique c'est la pression pub vs expérience utilisateur. Long débat que l'on va peut être finir par clore ; en tout cas je sais que notre régie pub y travaille pour finir par objectiver le sujet. Pour le reste si tu trouves des streams "pirate" c'est dommage mais c'est le jeu. On essaye évidement de limiter ce genre de pratique mais c'est techniquement impossible de tout contrôler/sécuriser (après tout qu'est ce qui empêche quelqu'un de re-streamer un flux tnt ? rien) -- Raphael Mazelier -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [MISC] RE: [FRnOG] eTF1 recrute
Ce thread a dérivé je crois et ce sera ma dernière intervention publique la dessus car je pense que j'ai déjà trop parlé. Sur le coté technique j'entends les critiques. Un nouveau player web et app/sdk est dans les cartons. J'espère qu'il améliorera grandement les choses. Le reste c'est du business. Le modèle historique de TF1 reste de proposer du contenu gratuit pubé. C'est un modèle complexe qui, que ce soit sur le linéaire ou sur le digital, doit toujours trouver un savant équilibre entre rentrées publicitaires, et donc pression publicitaire versus expérience utilisateur. Vu le succès de nos plateformes l’équilibre ne doit pas être si mauvais, mais évidement il ne peut convenir à tous le monde. Ceci dit nous savons tous que c'est un modèle qui est grandement remis en question par l’émergence des nouvelles habitudes de consommation de contenus vidéos, aka Netflix/Youtube, et même des initiatives originales type Molotov. Ce que je peux dire c'est que les dirigeants de TF1 en ont pleinement conscience et que les réflexions sont certainement en cours :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
On 22/09/2017 10:07, Wallace wrote: Ça ne solutionne pas le souci majeur de Docker et toute instance conteneur à savoir que les OS minimalistes dans les images sont - non sécurisées, c'est équivalent à un debootstrap or ceux qui mettent en prod des OS sans faire de hardening devraient changer de métier - rarement mis à jour soit par non mise à jour de l'image par les mainteneurs d'images officielles ou l'équipe de dev interne soit par non destroy / recreate d'une instance parce qu'au final ça marche et on a pas de mise à jour de code à faire dessus... Les conteneurs c'est bien pour faire des instances copies de prod pour du dev / staging / recette / préprod sans mettre les mêmes moyens d'infrastructure que la prod. On a vu plusieurs startup faire du full Docker sur quelques serveurs. Un simple audit de sécu et on passe de l'instance prod à la compta à la dev et au gitlab juste en ayant scanné les ports locaux des hôtes et en ayant mis un petit code de redirection de ports ... Je parle même pas de l'âge des instances qui pour certaines avaient presque 2 ans ... donc l'OS hôte Docker n'avait jamais été mis à jour, forcément faudrait arrêter la prod, la dev, le staging, la compta, le crm, l'erp, le partage de fichier, en gros arrêter la boite. La raison c'est trop compliqué de mettre en cluster sur des hosteurs de serveurs dédiés, sans blague. Non sérieusement en prod Docker ou tout conteneur on le conseil seulement pour faire un groupe d'hôtes qui accueilleraient le même type d'instances dans une DMZ avec un vrai firewall devant, avec une vrai politique de mise à jour et avec que des images custom avec un hardening bien fait mérite d'être en production. Mais rien que maintenir leurs propres images j'ai vu beaucoup de devops ou dev ne pas vouloir se lancer là dedans, du coup faire des VM ou baremetal avec un Ansible ou Puppet permet de concilier l'infrastructure as a code avec les bonnes pratiques systèmes en production. Je ne comprends vraiment pas cet argumentaire anti conteneur niveau sécurité. Au contraire le l'utilisation de containers dans un environnement type k8s me semble une bonne opportunité niveau sécurité. Cela permet de faire du rolling-update niveau container et niveau host (ce qui est en effet un argument pour ne pas faire d'update). Typiquement tout est éphémère, et tout est constamment mis à jour. Concernant les images en effet je suis d'accord qu'il faut les faire soit même (c'est même une évidence). L'autre immense avantage des architectures type k8s ce que l'on expose que ce qui doit être exposé, cela la limite la surface d'attaque externe. Concernant le filtrage interne des projets type calico permette un filtrage très fin (ala SecurityGroup Aws). Ce qui tu dis peut être c'est que faire du conteneur n'importe comment est dangereux ; oui comme une architecture classique. Bien utilisé cela permet une bien meilleure segmentation (c'est bien un des mantra de la sécurité hein ?). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
On 22/09/2017 10:53, Jean-Yves LENHOF wrote: Ca veut aussi dire avoir sa propre registry docker.. Et les solutions commencent tout juste à murir sur le sujet (haute dispo d'une registry ? ? une registry docker c'est un pauvre démon backé sur un filesystem / s3 ou autre. Il suffit d'en lancer plusieurs et de sauvegarder son backend. Par exemple chez nous on lance un registry par host k8s. Solution proxyfiée pour répartition sur plusieurs datacenter, etc) et je ne pense pas avoir vu tous les problèmes inhérents encore Après je ne suis pas contre docker... il y a des idées intéressantes surtout lorsque l'on va jusqu'au bout de la démarche avec un orchestrateur, maintenant si c'est seulement pour zapper les équipes infrastructures je suis moins d'accord surtout lorsque cela se fait au détriment de la sécurité Sans orchestrateur docker n'est qu'un outil qui unifie le paquetage d'une application (et c'est déjà énorme). Avec un orchestrateur cela commence à apporter une vrai nouvelle philosophie, aka se re-concentrer sur l'essentiel : l'applicatif. Il y aura toujours besoin de personne qui connaisse l'infrastructure mais peut être en effet qu'il n'y aura plus d’équipe infrastructure dans chaque société (devops toussa mais dans le bon sens du terme). En revanche on ne va pas se mentir les activités d'hébergeur/infogéreur à la papa vont souffrir face aux gros acteurs (AWS/GCE/Azure). Et c'est bien normal ils proposent des meilleurs infrastructures et plus de services. On peut encore se battre sur le prix mais cela va devenir dur. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
On 23/09/2017 21:58, Thomas Yoann wrote: Je suis desole mais ce genre de discour aws/gce/azure me fait plus que mal. Sans parler que oui je suis un hebergeur qui ne peux concurencer les enormes. Mais quand j'entend des clients qui me disent heberger des donnees de santee FR au US et ben je trouve que c'est un non sens. Il est vrai qu'il est dificile de jouer dans la meme cours mais a qui la faute!! Je pense peux etre a tord que les donnees FR doivent etre heberger en FR avec des societes qui paient leurs impots en FR. Je sais qu'il s'agit d'un pave dans la mare mais bon si personne ne defend le home made je ne sais pas ou l'on va. Si un certain nombre de personne pense comme moi n'hesitez pas a le faire savoir ;) Ps Raph juste un coup de geule perso, rien sur le discour du thread. Et dsl pour les fautes j'ai pas relu ;) Que l'on soit clair cette évolution ne me fait pas plaisir. Je suis et reste un mec de l'infra qui a racké ses premiers serveurs quand le format rack n'existait pas encore (bisous à ceux qui ont comme moi racké en masse des sparcstations/u1 en masse). Je ne veux froisser personne, je sais que tu as monté un beau truc du coté de Tours (qu'il faudra d'ailleurs que je visite à l'occasion). J'ai toujours apprécié l'artisanat et le homemade, mais aujourd'hui c'est sans doute par nostalgie. Malheureusement, et j'espère me tromper, je pense que le métier des petits/moyens hébergeurs va devenir de plus en plus difficile. Les utilisateurs attendent toujours plus de services, plus de scaling, avec un niveau d'automatisation plus élevé (la référence étant aws). Difficile pour les plus petits de monter une offre d'un même niveau. Pour la confidentialité/sécurité des données quelques points pour alimenter la réflexion : 1) Azure/GCE/Aws ont ou vont avoir des régions FR (justement à cause de cet argument) 2) On peut chiffrer toutes les données que l'on mets dans un cloud publique 3) A mon sens si tes données sont tellement sensibles tu ne les héberge pas chez un tiers (quelque qu'il soit). Le reste c'est une question de confiance. Je comprends bien que tu puisse faire plus confiance à ton hébergeur local qu'aux gafa, mais cela reste une relation contractuel. Pour les impôts complètement d'accord, mais je crois que le législateur va enfin tenter quelque chose. Mon constat est sans doute pessimiste pour l'hébergement pur, même si pour le moment il est encore facile de faire bien moins cher que du cloud publique. En revanche il reste un énorme marché pour quelque chose qui n'est pas adressé par les acteurs du cloud : l'intégration et le sur-mesure. C'est la dessus que nous pouvons/devons apporter de la valeur. D'ailleurs dans un cadre général : sysadmins/devops/netops nous sommes tous (ou devrions tous être) des intégrateurs dans le vrai et beau sens du terme. PS : évidement c'est un avis et je suis complètement prêt à en débattre sereinement. D'ailleurs j'ai loupé Frnog (pas cool de mettre ça au même moment que l'IBC) mais je serais présent à différents meetup en octobre pour parler de cela entre autre. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
ou les faire gérer. Donc les petits hébergeurs ont encore du travail clairement. Il y a plusieurs aspects qu'un DSI doit pendre en compte quand on choisit un cloud publique en effet. On peut citer le fait de ne pas se retrouver locké à tel ou tel provider (rien de bien nouveau quand on y pense) et justement l'aspect containerisation aide beaucoup, la sécurisation (nouveauté ?), les coûts (un cloud privé coûte encore moins cher qu'un cloud publique, encore qu'il faille prendre en compte le coût et la rareté des bons Ops) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Refonte infrastructure
On 26/09/2017 15:30, Sébastien FOUTREL wrote: Pour relativiser le propos, il faut faire la différence entre les infras que tu opères pour toi et celles que tu opères pour les autres. Oui complètement. Pour moi, dans mon coin faire du Docker/k8s pourquoi pas. Si ça pète c'est moi que ça regarde. Mais quand je dois opérer pour un autre avec des SLA et des avocats et que je lui dit que mes contraintes ne vont pas avec son contrat et ses SLA qu'il veut c'est plus pareil. On est d'accord. Et sur l'idée même du conteneur fait par et pour les devs (alors que PXE install, Debian et [Ansible,Chef,Puppet] ça marche tres bien et vite) je dirai que si on en est au point de ne pas savoir faire causer les gens du dev et du systeme on a pas des problèmes de technologies mais des problèmes de communication interne. Je crois que l'on dit la même chose. La technologie ne peut et ne dois jamais remplacer la communication. Encore une fois ce ne sont que des outils. Chacun utilise ce qu'il juge le plus opportun. Et pour finir je citerai un philosophe : "YOU BUILD IT, YOU RUN IT" Oula c'est très devops çà :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Attaques en série
Yep c'est une technique. (et cogent doit faire). Ceci dit il faut que ton trafic in passe déjà naturellement par le transitaire qui te fournit le port poubelle. Si n'est pas le cas tu es obligé de désagréger, ce qui est pénible si le ddoseur s'amuse à faire du random. Sinon vu que tu te fais quand même attaquer souvent je pense que prendre un transit qui propose une vrai solution de filtrage anti ddos sera un bon investissement. -- Raphael Mazelier On 27/09/2017 15:54, Mickael Marchand wrote: Yop Jérémy, on a déjà eu ca … y a longtemps ;) tant que tu n’as pas la capa de transit pour absorber tout l’entrant, tu n’as pas bcp de choix … (la course à la plus grosse …) pour moi, dans ton cas, le plus simple/meilleur compromis c’est encore d’avoir un port de transit en entrant qui ne sert qu’à filtrer (ACLs à négocier avec le transitaire mais 53+123 c'est facile à avoir normalement) en temps normal tu annonces rien dessus, ton traff passe par tes ports habituels avec ce transitaire, si DDoS, tu annonces les IPs à filtrer sur ton port filtrant (les /32 en no-export, si les /32 sont autorisées -> ca se négocie, sinon le /24 si t’as pas le choix, tjrs en no-export pour que ca reste chez ce meme transit), ton transit de prod est pas touché comme ca, au pire ca sature ton port de nettoyage (et impact limité au préfixe annoncé donc) à priori, un port 1gb/s peut suffir pour faire ca (donc pas cher à faire et facile à négocier avec un transit existant normalement) (à dimensionner en fonction de la taille de préfixe que tu annonces, un /24 tu voudras p-e plus que 1gb/s par ex) soyons clairs, ca soulagera pas le client impacté, mais au moins ton infra résiste « globalement » et tu peux dormir un peu mieux a+ Mik PS: petite dédicace à Arbor pour le nb de mitigations simultanées ridicule qui se fait pawner par ce type d’attaques tournantes ;) (quand le licensing vient tuer le concept, c’est dommage ;) Le 26 sept. 2017 à 22:08, Jeremy a écrit : Bonjour, Depuis quelques jours, nous recevons de nombreuses attaques semblant provenir d'un bot commandé (probablement un booter payant facturé à l'heure). On a relevé énormément de routeurs Mikrotik pas à jour qui sont commandés pour faire de l'amplification DNS avec spoofing. On tourne autour de 40-60 Gb/s en continue. La particularité de l'attaque est que le mec s'amuse à faire une rotation d'IP en piochant au pif dans les prefix qu'on annonce (on annonce l'équivalent d'un /19). Ca a tendance à fortement saturer les tuyaux (transport), et à faire sérieusement ramer notre infra Wanguard qui a du mal à suivre (de toute façon, comme ça sature au dessus...). J'ai l'idée de demander à Cogent (transitaire par lequel ça passe le plus, logique...) de rajouter une ACL pour filtrer le port 53 mais quid de notre capacité à résoudre les hostname depuis les root dns servers ?! Je pense que si on fait ça, on peut dire adieux à notre indépendance et bonjour à 8.8.8.8 partout (grosse galère en perspective). Pour le moment, je garde cette option en solution ultime. Bref, comme j'en ai marre de jouer avec BGP depuis samedi pour limiter la casse, je vais finir par rajouter un transitaire protégé le temps que ça passe. L'idée d'un tunnel GRE permettant de nettoyer le trafic avant d'arriver chez nous peut avoir du sens, ou alors un nouveau port de transit en 10G sur lequel on nous livrerais du transit déjà nettoyé. Si certains d'entre-vous ont une solution technique efficace capable de traiter très efficacement cette typologie, de mettre en place une solution d'urgence pour nous filer un coup de main, et si possible sans nous facturer les deux reins, ça serait très très apprécié. En MP si vous avez besoin de plus d'infos ! Merci, Jérémy --- Liste de diffusion du FRnOG http://www.frnog.org/ — Mickael Marchand, Responsable Equipe Réseau et Sécurité - Online.net --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] interxion aubervillier
Matin, C'est remonté vers 1h30 du mat par chez moi. J'ai perdu dans les 1db mais c'est pas très grave et de toute manière j'ai bien peur que la réparation soit assez temporaire. -- Raphael Mazelier On 07/10/2017 09:25, Pierre LANCASTRE wrote: Hello On a des equipements smartoptics qui mux et amplifient en entrée et sortie nos waves dwdm 1g/10g. http://www.smartoptics.com/wp-content/uploads/2015/08/SO-DS-M-1601.pdf On recupere les valeurs en snmp sur les différents points de l équipements. Je vous passe tout le detail sur la collecte, mais on récupère tout ca sur grafana. Ca permet de gerer l alerting et d avoir l historique. Du coup j ai ete content 5 min, quand j ai vu les 2 brins revenir a leur valeur initiale, avant d en voir 1 perdre 1.5 dB. Les valeurs de sortie d ampli n ayant pas bougé, il y a bien eu un probleme. Je vais voir si mon collegue a pu voir avec eux --- Pierre Lancastre Ingénieur Réseaux et Sécurité *-* SENSS - AS59798 *-* +33 7 64 07 26 11 Le 7 oct. 2017 02:41, "Michel Py" a écrit : Puisque c'est trolldi :P Est-ce qu'il y a des lecteurs qui ont eu que une des deux fibres coupées par le tractopelle ? Aie Aie pas taper pas taper :P Pierre LANCASTRE a écrit : Ici lien remonté depuis 20 min . Par contre perte d 1.5 dB sur un des 2 brins par rapport a avant. Tu avais une paire "classique" (tx/rx) et la soudure t'as rajouté 1.5 dB dans un sens et pas dans l'autre ? Je suppose que tes optiques sont DOM, tu pourrais partager les détails ? Pour des raisons obscures, je suis en train de jouer à l'apprenti sorcier avec (re)souder la fibre; la question c'est pourquoi pas... J'ai des centaines de paires et de kilomètres de fibre noire MMF pré-OM1 dont je ne sais pas quoi faire et j'aimerais bien comprendre pourquoi il y en a qui passent 10G et d'autres pas. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] - Recherche IOS le plus récent pour cisco 2651XM
Ca l'air sympa ces petites bebetes. Je ne connaissais pas. -- Raphael Mazelier On 15/10/2017 18:07, Benjamin SCHILZ wrote: Bonjour, Opengear c’est très bien mais un peu cher en effet. Sinon tu as : https://www.get-console.com/shop/en/device-servers/117-airconsole-ts-4n-port.htmlUn peu cheap sur l’apparence mais ça marche bien et pas cher. Benjamin --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Foramtion Openstack
Si vous voulez du stockage objets je vous conseille de regarder du coté d'openio. -- Raphael Mazelier On 19/10/2017 09:28, renaud.fle...@free.fr wrote: Bonjour, Je vous propose plutôt de vous orienter sur du CEPH voire du GlusterFS. La virtualisation est l'un des axes majeurs d'openstack... - Mail original - De: "Guillaume LAPOUGE" À: "Raphael Maunier" Cc: "frnog-...@frnog.org" Envoyé: Jeudi 19 Octobre 2017 09:23:08 Objet: RE: [FRnOG] [BIZ] Foramtion Openstack Nous souhaitons remplacer notre stockage monfodb gridfs par du swift en fait. La parti virtu sera secondaire. -Message d'origine- De : Raphael Maunier [mailto:raphael.maun...@gmail.com] De la part de Raphael Maunier Envoyé : jeudi 19 octobre 2017 09:01 À : Stephane Benfredj Cc : Guillaume LAPOUGE ; frnog-...@frnog.org Objet : Re: [FRnOG] [BIZ] Foramtion Openstack +1 pour Objectif Libre Par contre, je signale tout de meme que OpenStack, ce n’est pas magique et que meme si c’est “relativement” simple a installer. Pour maintenir la solution en condition opérationnelle et surtout faire du debug ( des bugs y en a des tonnes ), il faut une équipe bien rodée et des clients patients :) OpenStack c’est vraiment fait pour de la grosse infra, et surtout, il faut en avoir 2. Les montées de versions sont … pas impossible, car rien blablabla… et Ben en fait si :) Raphael On 19 Oct 2017, at 08:56, Stephane Benfredj wrote: Bonjour Guillaume, Le jeu. 19 oct. 2017 à 08:41, Guillaume LAPOUGE a écrit : Bonjour, Je recherche une formation openstack sur RENNES ou NANTES. Nous souhaiterions que cette formation sois orientée autour de swift en particulier mais qu'elle balaye quand même l'ensemble de cette solution cloud. Avez-vous des organismes ou proposez-vous une telle formation ? Cdlt Je suggérerais de te rapprocher de Objectif Libre qui a d’excellentes compétences et qui organise ce type de formation. Bien cordialement Stéphane --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [ALERT] s3.amazonaws.com may be down
On 15/11/2017 23:50, Nathan MOREAU wrote: Bonsoir, Pour répondre à M. Raphël Mazelier et ne voyant pas les réponses ici mais uniquement par mails. Ah ce n'était pas fait spécifiquement exprès. On me dit que : "Quel est le rapport avec l'incident initial ?". J'ai une impression d'une dégradation de l'AS5511 au fur et à mesure que l'on avance dans le temps, le BGP leak étant peut être pas de leurs faute. Difficile d'incriminer 5511 si tu connais la root-cause de l'incident d'aujourd'hui. Après oui la communication n'est pas fameuse, ni coté OT, ni coté level3. Quant à la dégradation difficile à dire. La connectivité internet mondiale et les différends (des)accords entre opérateurs pourraient faire l'objet de chapitres entiers d'une encyclopédie. Des PNIs saturés cela a toujours existé et les conflits en résultant aussi. (et cela à toujours fait râler les utilisateur qui se sentent pris en otage, oui) Pour le reste, comme les saturations hebdomadaires entre gros PNI (LibertyGlobal sur Paris) ou encore les Tier1 (Sparkle alias Seabone sur Marseille) et bien d'autres, sont toujours présentes. Je ne peux que constater, et cela me gêne de ne rien pouvoir entreprendre derrière tout ça. OBS/Orange est une entreprise privé. Elle va réagir en fonction des divers retours fait de ces utilisateurs (ou pas). C'est ta seule méthode d'action, à part aller voir ailleurs. J'essaye de faire en sorte de défendre l'Internet neutre. Le problème de l'AS5511 est que ça politique de réseau est basé sur un ratio de trafic assez strict. Rappelez-vous l'histoire avec Cogent (trafic majoritairement à destination de l'hébergeur MegaUpload) : https://www.arcep.fr/fileadmin/reprise/textes/juris/2012/12-d-18.pdf A l'époque c'était inimaginable que de tels acteurs puissent pas convier d'un accord à l'amiable pour upgrader l'interconnexion, il a fallut passer par la justice. Aujourd'hui je ne comprends toujours pas les pratiques menées par AS5511. Ce n'est pas toujours simple d'upgrader, il existe plein de contraintes techniques et/ou politiques (et pas sur que ce soit toujours 5511 le méchant dans l'histoire). Peut-être suis-je dans l'erreur, et que quelque chose m'échappe, à vous de me le dire. Je ne sais pas. Mais dans le style non neutre il y a en France bien pire... -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] L'ARCEP publie l’édition 2017 de son observatoire de la transition vers IPv6
On 22/12/2017 19:55, David Ponzone wrote: +1 Sans parler des trucs qui marchent pas ou mal, de la complexité inutile pour refaire en v6 ce qu’on faisait en v4, des implémentations encore boiteuses ou partielles dans certains CPE. C'est trolldi c'est permis ? La question aujourd'hui c'est qui croit encore qu'ipv6 va remplacer ipv4 ? En 1999 ipv6 c'était le futur. En 2004 ipv6 allait remplacer ipv4 complément dans maximum 2 ans. En 2015 c'était la fin, il n'y avait quasi plus d'ipv4 publique disponible. Et finalement ? Pendant assez longtemps je faisais l'effort de déployer du dual stack, mais je me demande si je vais continuer. Je ne vois même plus l’intérêt puisque finalement les services accessibles en ipv6 fonctionnent moins bien leur pendant en v4 (sans doute car ils sont moins maintenus fautes d’intérêt ?) L'ennui c'est qu'on a finalement quelque chose qui marche (ipv4) avec un remplaçant qui n'a pas apporté beaucoup d'amélioration aux défauts/manques du protocole initial. Sans compter qu'en 2017 il n'est toujours pas possible de déployer un vrai réseau opérateur en v6 only... Finalement avec le recul peut être qu'une rupture technologique aurait peut être mieux réussi ? Allez zoyeuses fêtes les admins du net :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] || Convertisseur FO et Switch SFP
On 07/01/2018 00:53, David Ponzone wrote: J'avoue que j'ai pas bien compris si tu fais la conversion chez chaque client, ou au niveau de l'armoire. Si c'est tout au niveau de l'armoire, je ferais simple, avec du Cat 3750-12S-S d'occase. Avec 6 SFP SX et 6 SFP 1000baseT (de bonne qualité), tu gères la conversion de 6 FO avec un seul équipement. Le 3750 a une alim AC et une DC, donc tu peux redonder côté PS en ajoutant un RPS675. Le 3750 est un modèle éprouvé, archi-stable, et si tu en ajoutes un second plus tard, tu peux les stocker (pas utile dans ton cas cependant). Yes le 3750-12S, LE switch d'aggreg. A l'époque (2012) il coûtait fort cher mais maintenant cela se doit trouver pour une bouchée de pain. En revanche les RPS je n'ai jamais été convaincu (enfin j'ai été convaincu du contraire plutôt). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: Trafic input délirant sur Equinix-IX PA3
Ce n'est pas le problème habituel de l'unknown unicast sur les IX dont le trafic est fortement asymétrique ? (Equinix-IX paris étant majoritairement un IX de backup). Parce que bon des pingers c'est pas très dur à mettre en place... On 15/01/2018 20:15, David Ponzone wrote: Tu pourrais vérifier une ou 2 IP destination de ce trafic, tu vérifies dans tes routes BGP quel est le next-hop sur le LAN Equinix-IX pour ces IP, histoire de voir si tu trouves les mêmes que moi. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: Trafic input délirant sur Equinix-IX PA3
On 16/01/2018 00:03, Olivier Benghozi wrote: Quels pingers? Une session BGP ça keepalive classiquement toutes les 30 à 60 secondes (donc un TCP dans les deux sens), et si pas de BGP, pas de traf. Il est vrai qu'en cas de BGP uniquement avec des RS, et de flux asymétriques, tu peux avoir des switches qui ne voient passer du traf que dans un seul sens en dehors des ARP. C'est à cela que je pensais. De nombreux IX ont implémenté des pingers pour pallier ce problème sans pour autant augmenter l'aging. C'est pour ça qu'il faut configurer le MAC aging à 4h sur un IX, pour correspondre à la valeur d'expiration du cache ARP par défaut la plus longue et pourtant répandue, cad Cisco (bien que ce soit une valeur débile). Yes. Ceci dans le cas qui nous intéresse ca a l'air de leaker entre autre du trafic entre toi et un de tes peers directs, donc nous ne sommes pas dans ce cas, et c'est encore moins beau ;) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Aide pour le choix d'un cluster de routeur
On 31/01/2018 21:28, Guillaume Barrot wrote: "Mon premier problème se porte sur le choix des routeurs. J'ai eu diverses propositions notamment avec du Cisco et Juniper, cependant je me demande si ce n'est pas surdimensionné pour ce type de besoin." Prends 2 x ASR chez le premier broker venu, ça suffira bien, et au moins tu auras la doc en ligne pour faire globalement tout et n'importe quoi. 2 x ASR1001 pour 1G de transit (vu que tes clients ont besoin de 10M chacun, ça suffira bien en capacité max), tu vas taper dans les 1000/1500€ pièce grand max. Si besoin ça tiendra la full route, mais bon, je pense que 2 liens chez un transitaire unique, avec annonce d'une default, ça suffira bien pour commencer. Par contre si demain t'as besoin de faire d'autre trucs un peu touchy, ben tu pourras, c'est une des plateformes les plus riches en feature (c'est le 7200 des années 2010 quoi). Après, le matos c'est le sujet ultra simple. Le choix du transitaire là, par contre... +1. Très bon choix un ASR1K. Après si vraiment tu n'es pas à l'aise avec de la conf cisco tu peux aussi faire la même chose en soft avec whatever serveur et démon de routage. Cela prendra sans doute plus de temps et sera un peu plus cher (et moins intégré). Pas besoin de full view. C'est très surfait la full. A part quand tu es un SP qui a besoin de la re-annoncer à tes clients, 99% des AS n'en ont pas besoin. En général en 10K routes tu tiens largement tes destinations que tu veux gérer (que ce soit niveau quali ou niveau coût). Je partirais quand même avec deux transitaires quitte à être dans une configuration actif/backup (avec annonce de la default des deux coté et pref locale). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Ingénierie de trafic
Bonjour la liste, Cela fait longtemps que je n'ai posé de question technique, ni même fait de réseau sérieusement alors soyez indulgent :) J'ai besoin (temporairement, car oui je vais upgrader, juste que vous savez bien que le temps de commander des crossco et autre c'est pas instant) de faire un peu de trafic engenering pour laisser mon out non saturé. Quelques questions donc : Comment faites pour splitter le trafic à destination d'un AS vers X transitaires quand les as-path sont très différents ? vous normalisez la longueur des as-path ? ou vous splittez sur des pfxs connus ? Dans le cas du split à base de pfx, comment déterminez vous les bons pfx par destination ? Exemple : sur 3215, il y a une liste de pfx connues qui correspond à des zones et/ou typologies (ex trafic mobile vs fixe) Pareil sur 5410 et 12322. Merci d'avance. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] FRnOG 30.0 - BETA
On 20/02/2018 12:02, Philippe Bourcier wrote: On va faire une table-ronde sur SD-WAN "Et si on collait tout sur Internet ?". C'est un sujet mi-tech, mi-business... et je cherche encore quelques personnes intéressées pour débattre sur ce sujet. C'est un sujet troll surtout non ? tu n'as peur que ca dérive ? -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [JOBS] Etf1 recrute des ingés systemes/devops
Bonsoir la liste, Encore une annonce d'emploi un peu HS, mais je sais que beaucoup de sysadmins sont abonnés a cette liste alors je tente ma chance. So ; nous recherchons deux profils adminsys/ops/devops (peu importe comment vous vous définissez) afin de nous accompagner dans la belle transformation amorcée par chez nous. (devops/cloud/toussa). L’équipe est sympa. Le terrain de jeu est vaste. (système, réseau, vidéo) La stack technique est assez moderne (k8s, go, cloud, etc...). Les ambitions sont grandes et la roadmap dense. Le poste est situé à Boulogne dans la tour TF1, on a un petit peu de télétravail possible. La rémunération sera dans les standard du marché, enfin j’espère (disons entre 40K et 62K selon expérience) hors avantages (participation, épargne salariale, ce, etc...) Je suis évidement dispo pour en discuter en PV. Ci après la fiche de poste : Ingénieur Système ""OPS/DEVOPS"" Profil : - au moins une 1ere expérience significative - connaître les environnements web / HA - expérience de la production sous linux - team player/open-mind Technos : - maîtrise de linux (99% du parc en centos) - maîtrise des technos web (nginx, haproxy, varnish, etc) - bonne connaissance des technos associés (redis, BDDs postgres, ES, etc...) - connaissances des technos d'automatisation : puppet, ansible, jenkins... - connaître un langage de programation (python, go par exemple), capacité à automatiser - connaissance de base du réseau (L3/L2, Firewalling, Routage) - gros bonus : connaissance de kubernetes, cloud AWS. Société : eTF1 : en charge de toute la partie digitale du groupe TF1. On fait des sites web et on diffuse de la vidéo; au sein de la DTD (60 personnes environ, 40 dev, 20 transverses) Équipe IOPS (12 personnes ) nous, équipe qui gère les infras systèmes, réseaux, stockages, vidéo et production applicatives. A bientôt, -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Ingénierie de trafic
On 23/02/2018 09:39, Xavier H wrote: Bonjour, je pense qu'il suffit de chercher un peu ... Par exemple, la page https://ipinfo.io/AS3215 te donne toutes les plages IP de l'AS 3215. Et tu as des blocs qui s'appel "Orange Mobile" par exemple. Je pense que c'est les plage des mobiles ! J'avoue que c'était pas hyper dur. Merci ! -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Ingénierie de trafic
On 23/02/2018 10:18, David Ponzone wrote: Pardon! Mieux pour pas se faire blacklister par la RIPE DB: whois -r -i mnt-by FT-BRX | grep -B 2 'Orange Mobile' Au final je me suis fait ma petite moulinette qui crée mes prefix-list. Mais le résultat n'est pas très probant en terme de trafic, tout au plus 5% de mon contenu. Alors soit les gens qui lisent des vidéos sur device-mobile le font quasi uniquement connecté en wifi (ce dont je doute), soit le réseau mobile orange a des gros cache web en sortie. Je sens que ça va se terminer en gros découpage crado des pfx reçu. Un tool qui va bien pour faire ça ? -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] avis arista 7280R(2) comme routeur edge avec 4 fullview bgp
On 29/03/2018 20:21, Guillaume Barrot wrote: Avant de te répondre dans le détail, comment arrives-tu à 4 fullview ? Tu fais de la DFZ dans des VRF ? Tu as besoin de combien de ports / type ? Meme question : pourquoi avoir autant de full (et meme besoin de full tout court, tu es SP ?). Pour le reste Arista : the new kid on the block, pas parfait mais pour du simple ca fait très bien le taf. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Logiciel schéma réseau
On 04/04/2018 12:54, Michael Hallgren wrote: Le 2018-04-04 11:50, Alexis Lameire a écrit : J'ai pas trouvé mieux que de les faires en latex avec Tikz, je me contente de forme simple mais au moin c'est hyper lisible et facilement maintenable même pour des shèmas complexe ! Voilà ! Me too. Personnellement, meme si c'est mac-only et payant je n'ai jamais trouvé mieux qu'omnigraffle. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Switch / Routeur 100G cheap or not ?
Bonsoir la liste, Étant à la recherche de matos edge ayant de la densité en port 100g et 25g, je suis en train de regarder les différents acteurs. Niveau hardware ça sera visiblement le même partout, Broadcom et x86. Fine. Le choix se porte donc sur l’intégrateur du dit hardware et le NOS. Niveau fonctionnalité j'ai besoin de bien peu de choses : BGP simple, pas de full (max 10k), ECMP 64way ça serait bien, sflow, et c'est à peu près tout. On aurait donc : - Arista 70XX, 71XX : ça à l'air d’être hype, EOS à l'air cool, mais c'est trop cher (le support notamment) et ils ont l'air rigide (les optiques ça se règle mais sur le principe déjà). On sent un peu la boite qui commence à être en position de force... - Juniper QFX5200 : quid de la stabilité ? budget ? et du whitebox : - Edgecore - fs.com qui fait des switchs maintenant - et je viens de tomber la dessus NETBERG sur bm-switch à des prix imbattables , surtout avec un package avec l'os broadcom ICOS. La question à 100 balles : qui connaît ces derniers ? et ICOS ? et aurait même de l'expérience en prod avec ca ? sur le papier c'est dans le registre du trop beau pour être vrai. Sinon niveau NOS plus établi des avis éclairés entre Cumulus, Pica8, Bigswitch ? Bon trolldi, -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Switch / Routeur 100G cheap or not ?
On 18/05/2018 10:06, BLANCPAIN Nicolas wrote: Question idiote sans doute, mais pourquoi pas les classiques : Cisco, Alcatel, HP ? Trop cher ? - Cisco : hors de prix, avec un NOS sur ces modèles contestable on va dire. - HPE : ils n'ont quasi plus de nouvelle gamme, mais je vais demander quand même vu que c'est ce que j'ai actuellement (HPE 5200, 12500) et que j'en suis plutôt content. Ceci dit chez HP c'est un peu le souk niveau gamme. Sur leur site tu trouve du HPE, du ex-procurve, du Aruba, du Arista, et même de l'Alcatel... - Alcaltel : ils existent encore ? :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Switch / Routeur 100G cheap or not ?
On 18/05/2018 10:27, Julien Thomas wrote: Salut, Dell série Z! http://www.dell.com/en-us/work/shop/povw/networking-z-series Tu peux même choisir l'OS que tu mets dessus derrière (Dell OS9, 0S10, Cumulus, etc.) Le support Dell network est réactif et compétent et le prix est très correcte par rapport à la concurrence, donc c'est vraiment pas mal. Mhm les pricing que j'avais eu n'était pas fou fou. OS9 , OS10 je n'ai jamais testé. C'est censé être stable et avoir des features en L3 ? -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RE: Outils cool, qu'utilisez-vous ?
On 23/05/2018 10:53, Kevin Labecot wrote: MobaXterm mais Windows only à mon plus grand malheur... Et impossible à faire fonctionner sous Wine pour ceux sous Linux/Mac OS. Pour les terms on a le choix des armes sous Linux tout de même (Terminator, Tilix, même gnome-terminal est maintenant utilisable). Et puis avec un tilling wm on a encore plus de choix. PS : le meilleur reste iterm2 sous mac évidement :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RE: Outils cool, qu'utilisez-vous ?
On 23/05/2018 17:26, Michel Py wrote: Ah c'est donc çà qui se passe. Je confirme, avec certains matos çà plante. En général sur Cisco çà se passe bien, mais j'ai quelques antiquités qui passent à 100% CPU. > David Ponzone a écrit : Oui, le produit est automagique, mais ne pas pouvoir restreindre le poller à ne prendre que l’essentiel a un arrière-goût de "société de consommation" désagréable. Bon puisque je suis lancé sur Observium/LibreNMS. Donc on peut désactiver quelques MIBs pour rendre cela moins pire. Maintenant le fond du problème c'est que le poller d'observium est complètement naif pour dire les choses gentiment. Basiquement il fait pour chaque device des gros snmpbulkwalk de quasi toutes la MIB à chaque fois. Le seul parallélisme étant réalise au niveau host. L'ennui c'est que les devices n'ont pas été prévu pour ça (surtout quand on a des gros stacks avec genre +1000ports). Il faudrait que je retrouve le papier de juniper qui expliquait clairement qu'il ne fallait pas faire ça mais faire des snmpget ciblé. OK on peut se dire que les constructeurs ont tord mais ce n'est pas très constructif. Surtout cela ne sert globalement à rien de tout reparser (un port va t'il changer de type à tous les polls ?). Un poller plus intelligent (par exemple celui de cacti/spine) sépare les choses en deux : - un poll de découverte des interfaces ou autres (et il le cache), poll occasionnel, à coup de bulkwalk ciblé. - un poll régulier à coup de get ciblé sur les oids précis de ce que l'on a autodécouvert. Cerise sur le gateau on peut // les get sur l'ensemble des oids/devices que l'on avait découvert ce qui va bcp plus vite au final. C'est plus au moins ce que j'avais patché à l'arrache dans observium ce qui me permettait de poller mes stacks d'EX3300 sans tout arracher le tout dans un temps raisonnable. Il faudrait que je retrouve si ça intéresse du monde. Reconnaissons toutefois qu'Observium est un bon outil qui permet en 3 clicks de superviser son matos réseaux. La gui est très joli, il faut juste pas regarder sous le capot :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] DDoS / analyse de traffic
Le 26/02/2015 21:10, Jeremy a écrit : Prend une licence chez Wanguard va :) Je trouve que ce soft a un très bon rapport qualité/prix. Évidement c'est loin d’être parfait, mais à ce tarif c'est imbattable. Le support est réactif qui plus est. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Remplacement solution IOS SLB
Le 02/03/15 17:18, Jérôme BERTHIER a écrit : Au final, on a surtout besoin des fonctionnalités test de vie + injection de route. La partie LB est facultative puisque on a déjà un RR DNS. Généralement je fais ça avec exabgp, avec un heathcheck custom. Ça ne fait pas LB, encore que tu puisse activer le mutlipath bgp sur tes routeurs (bon en revanche pas de poids). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Fin de la panne du SEA-ME-WE-4 au 6 mars ?
Le 11/03/15 16:31, Remi Paulmier a écrit : Bonjour la liste, Quelqu'un a-t-il des nouvelles sur la panne du SEA-ME-WE-4 datant de février, et sensée être réparée le 6 mars dernier ? J'ai l'impression que nous sommes toujours sur le circuit de backup, et ca rame De mon coté j'avais constaté une énorme dégradation entre Paris et Singapour via Tata (qui selon toute vraisemblance prenait ce chemin), qui a été réglée le 25 février. Après la situation doit être différente selon les transitaires. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] [TECH] Boitier VPN + SWITCH + FW
Le 24/03/2015 08:02, Pierre LANCASTRE a écrit : Bonjour, Il y a les entrées de gamme fortinet (60 a 90D). Sinon pour du port sfp, il faut la gamme 100-D mini (sauf erreur) La GUI est très sympa (le cli pas du tout, compare a du Juniper). En tout cas le rapport features/perf/prix est très intéressant. Fortinet en complément de SRX peut être intéressant oui. Dans les dernières versions la stabilité s'est largement amélioré et en effet la gui est très agréable. Pour moi il s'agit des deux fw constructeurs les plus crédibles. (qui d'autres d'ailleurs ? il y avait bien stonesoft avant le rachat par mcaffe, mais sinon ?) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] [TECH] Boitier VPN + SWITCH + FW
Le 24/03/15 10:25, Louis a écrit : Bonjour, Fortigate est un bon produit à tout faire qui en plus est très pratique pour faire du debug (la fonction "diagnose sniffer packet " pour faire un dump du trafic n'existe pas à ma connaissance sur les SRX). Ceci-dit, j'aurais un peu peur de faire du BGP sur ce genre de boîtier alors que je le ferais sans soucis sur les SRX. Quel est votre retour avec le routage dynamique sur fortigate? Moyen. Cela fonctionne pour des fonctionnalités basiques. Et pour le coup tu es obligé de passer en cli (il manque vraiment beaucoup d'options dans la gui). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] [tech] probleme axialis compte sip down
Joli. Mais il s'agit de Le 26/03/15 16:07, Rémi Laurent a écrit : * David Ponzone - 26-03-2015 à 15h52: Ils ont pas de support ? http://www.axialis.com/support/logo.jpg Joli. Mais il s'agit de la société Axialys :) Et oui ils ont un support. Après si la téléphonie est KO, ça sera difficile de les joindre par ce bais. Leur site web est cassé btw. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Switch SFP
Le 30/03/15 17:34, Sébastien 65 a écrit : Oui, le 3750G-12 n'est pas mal mais je n'ai aucune idée de son prix en neuf/reconditionné... Ah ça le switch d’agrégation avec que du SFP on l'a tous cherché un jour. Je confirme que le 3750G-12 (avec même l'extension 4x1G) est un bon produit. Sans doute encore un peu cher. Sinon chez Juniper je viens de voir l'EX4300-32F qui intéressant point de vue densité de port je trouve : 32 x Gigabit SFP + 4 x 10 Gigabit SFP+ + 2 x 40 Gigabit QSFP+. (bon on s'est éloigné du sujet et du prix je pense). Cdt, -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Configuration hardware serveur BGP quagga
On routait déjà des full-view avec zebra sur des P4C moins puissants que ça, avec moins de RAM. Bon, elles ne faisaient que 250k routes à l'époque. Oh ça me rappelle mon routeur chez AS16363. A l’époque un bon vieux PII 400 avec 256Meg de ram. Plus de 3 ans d'uptime quand je suis arrivé. C'était quand même assez lent à converger :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Configuration hardware serveur BGP quagga
OpenBSD peut devenir une bonne alternative de base et avec nsh (CLI) encore mieux... OpenBSD est un super OS que je conseille. En revanche je conseille quand même bird par rapport à OpenBGPd. En terme de flexibilité c'est quand même meilleur, et bird marche très bien sous Open. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] recherche hébergement en Datacenter pour 60 racks dans l'Essonne
Le 14/04/15 15:07, David Ponzone a écrit : C’est beaucoup 10kVA par rack non ? 60 racks de 10KVA ça commence à faire un paquet d’équipements... -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Configuration Fibre SFR
Exactement pour toutes ces raisons il me semble. Oui et surtout pour faire point de démarcation. C'est un grand classique, avant on faisait ça systématiquement sur des RAD, maintenant SFR deploie du Huawei. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Modèle économique des interconnexions en datacenter
Le 05/05/15 10:08, Jérôme Nicolle a écrit : Bonjour à tous, Hello Jérôme, snip Les principaux modèles rencontrés sont : - DIY : posez ou faits poser des câbles point à point. CAPEX pur, non déterministe car coût réel fonction de la longueur du câble A la TH2 par exemple. - MMR au réel : facturation one-shot de la mise en place d'une interco, CAPEX pur A la Iliad par exemple. (ou avec un opex quasi nul) - MMR de rentier : facturation périodique de l'usage d'une interco, avec composante de FAS dans la plupart des cas A la Equinix, Telecity. Chaque site a sa propre politique et grille tarifaire, et ce n'est que dans de très rares cas que les délais et coûts sont déterministes. Ce qui pose naturellement deux problème majeurs du point de vue de l'utilisateur : difficile de prévoir les délais de livraison d'un service client, et difficile de connaitre à l'avance sa rentabilité. Les priorités sont différentes pour chacun de nous, et je tenterai de les définir de la façon suivante : - CAPEX de l'interco - OPEX éventuel de l'interco - Délai de mise en service - Fiabilité dans le temps - Coût de dépose éventuel Ce à quoi il faut ajouter pour certains la diversité de l'offre : cuivre, coax, fibre MM ou SM… Une fois les critères définis, à priori pour chaque site, on peut les intégrer dans un SI qui tentera d'estimer les délais (pour le service delivery) et les coûts (pour l'avant-vente). Sauf qu'avec autant de variation d'un site à l'autre, en tout cas sur la structure de coûts, ça complique l'implémentation au point que j'aimerais avoir votre avis pour m'assurer de n'avoir pas oublié de cas de figure. En terme de délais, là c'est carrément folklorique : de 2h à 2j pour certains, de 6 à 14 mois pour d'autres… J'ai pris le parti d'ignorer cette composante pour l'instant. Mais la question sous-jacente est finalement plus importante : c'est quoi le bon modèle ? Qu'est ce qui convient à la majorité d'entre nous, autant en tant qu'opérateur qu'en tant que datacenter ? Je pense que tu n'as rien oublié, peut être la qualité/rapidité d'intervention en cas de souci. Quel est le bon modèle ? De mon point de vue petit opérateur clairement je préfère un modèle à la TH2 sans MMR, avec un FAS au linéaire (mais qui de toute façon est souvent inférieur au FAS des autres modèle). Outre l'aspect financier, c'est surtout l'aspect rapidité et fiabilité qui me font préférer ce modèle. TH2 si tu débrouille bien, en 1j ouvré tu as ton câble, ça marche et tu n'en entends plus parler. Que dire des autres modèles avec MMR ? il y a des endroits ou ça marche à peu près, mais systématiquement tu perds du temps à la mise en œuvre. Et après il y a des endroits ou c'est une véritable catastrophe, écrasement de ccr, ccr qui flap a chaque intervention en MMR, j'en passe et des meilleures. Je conçois que pour un datacenter le modèle avec MRR soit plus rentable et pérenne (c'est à dire ne pas se retrouver avec des câbles partout). Mais pour que cela soit viable il faut être irréprochable sur la gestion des MMRs. Autant dire que ce n'est pas possible. Un modèle intermédiaire que je verrais bien : - passage de câble par le datacenter only. - NRC fixe (mais pas délirant, de l'ordre de 400E), délai 3J max. - câble direct (ou splicé a la limite) mais avec chemin imposé (aka on passe pas partout, n'importe comment) - MRC symbolique (entre 20e par cable ?). Le tout avec une gestion stricte des câbles, et campagne de dépose de câble non identifié régulière. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Modèle économique des interconnexions en datacenter
Le 05/05/15 12:55, Clement Cavadore a écrit : Il me semble qu'il serait plutôt fair d'avoir la politique suivante: - Avoir des MMR - Appliquer des FAS (margés) sur la pose de breakouts entre la salle/baie du client - Appliquer (éventuellement) un récurrent assez faible sur la présence de câbles (breakout) dans les chemins de câbles. - Appliquer un coût raisonnable (one shot) à la prestation de cablage-décâblage de positions en MMR - Proposer les intercos directes, mais sur devis, et avec un récurrent mensuel (pour les cas spécifiques), afin qu'ils soient déposés après usage Cela permettrait, à mon sens: 1- De limiter la stratification de câbles dans le faux plancher. 2- D'inciter à la pose de grande capacités dans les câbles breakouts. 3- De recycler les positions inutilisées. 4- De faire un peu de blé sur les xco, sans pour autant violer le client à chaque nouvelle interconnexions (coucou Equinix !) 5- De permettre les intercos directes pour les situations critiques/limites en terme d'affaiblissement. Le modèle de telehouse2 est vraiment super pour favoriser les interconnexions, mais malheureusement ingérable sur le long terme (du point de vue explitant de salle). Et franchement, des capex+opex à la Equinix sur les PAIRES vers les MMR, je trouve que c'est du vol (surtout quand on connaît la grande qualité de leurs xco). Oui c'est ce que je pensait aussi il y a quelques mois. Mais depuis j'ai aussi eu d'autre mauvaise expériences (et pas que chez nos amis du 93) qui me font penser que dès qu'on passe par une MMR c'est l’échec. En tout cas de mon point vue opérateur passer par une MMR n'a quasiment aucun avantage vu que : - c'est souvent plus cher - c'est toujours plus long en terme de délai, car il faut toujours s'y reprendre à 2/3 fois avant que le ccr complet soit fonctionnel. Je ne parle même pas du temps de réaction des équipes du DCs... - c'est toujours moins fiable (le nombre d’élément intermédiaire pouvant foirer étant beaucoup plus important). Et je ne parle même pas de le qualité des patchpanel utilisé ou autre dans certains DCs... qui font que pour de l'intra-dc on arrive à des atténuations sur-réaliste. (j'ai quelque bon exemple au US). Le seul avantage que je verrais ça serait la possibilité de pré provisionner en effet. Point de vue exploitant datacenter il faut faire un choix : - avoir un datacenter qui favorise les intercos (en direct donc, mais pas en bordel comme je le disais dans mon mail précédent) - avoir un datacenter qui favorise la pseudo propreté (avec MMRs donc) mais qui limite forcément le buisness Pas facile. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Solution routeur virtuel
> Juniper : vSRX (Firefly) ou vMX $ Yep, et chez juniper il y aussi vRR (qui est fait pour ça à priori). Autres : libre avec EXABGP, BIRD, whatever Oui mais dans ce cas pas d'Isis, pas de MPBGP. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] emulateur
Le 12/05/15 10:25, David Ponzone a écrit : Un shell UNIX-like pour Windows ? Il faut mettre un truc du genre CYGWIN, mais ça transformera pas Windows en Unix… Un émulateur de terminal pour Windows moins daubique que HyperTerm ? https://www.vandyke.com/products/securecrt/windows.html Oui ou putty/kitty en opensource. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
[TECH] Re: [FRnOG] [BIZ] Solution routeur virtuel
Le 20/05/15 16:13, Guillaume BARROT a écrit : Si : http://manpages.ubuntu.com/manpages/trusty/man8/isisd.8.html Alors dans quagga effectivement il y a une branche avec un début d'isis. et re-si https://gitlab.labs.nic.cz/labs/bird/blob/fed1bceb2cf6d424396347921cfc9775c9a8af9b/proto/isis/isis.c et aussi dans bird, mais c'est hautement expérimental de leur propre aveu. et pour MPBGP, si tu sais pas faire dans EXABGP, y a de grandes chances que ça n’existe juste pas https://github.com/Exa-Networks/exabgp/wiki/Configuration-:-capability https://github.com/Exa-Networks/exabgp/wiki/Configuration-:-family https://github.com/Exa-Networks/exabgp/wiki/Configuration-:-L2VPN-VPLS A part des trucs méga-exotiques ou très très récents, y a quasiment tout BGP ! Dans exabgp oui, mais ce n'est qu'un 'injecteur'. Pour le dataplane : http://dpdk.org/ Avec beaucoup de développement/temps , ouais on va y arriver. Donc non honnêtement il n'y a pas encore de soft opensource qui font correctement isis (ça ça va s'arranger, ce n'est qu'un protocole de routage de plus, avec certes le fait de devoir gérer son propre l3) et MPBGP (désolé mais je ne connais pas encore de stack MPLS opensource, a a part sous openbsd, mais c'est marginal). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Problème chez level3 ? avec Free
Grosse perturbation dans la force ce matin. http://www.theregister.co.uk/2015/06/12/level_3_down_after_routing_through_malaysia_like_idiots/ Le 12/06/15 16:22, Thierry Del-Monte a écrit : Nous rencontrons des problèmes entre level3 et Free, et certains clients nous remontent des problèmes d'accès depuis la plaque nord américaine utilisant Level3. Nous avons fait le nécessaire en interne (reroutage), et ouvert un incident chez level3. Mais avez-vous les mêmes symptômes ?? -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Switch 10G
Le 22/06/15 12:10, David Ponzone a écrit : T’as pensé à Cumulus ? Entre le prix de l’OS et le prix du switch bare metal, tu risques quand même d’avoir du mal à tenir dans ton budget, mais tu as 48 ports 10G: http://cumulusnetworks.com/support/linux-hardware-compatibility-list/ Sur le papier le juniper EX4300-32F n'est pas loin de ce que tu cherches. 32 ports SFP 1G, 4 ports SFP+ 10G, 2 port QSFP 40G. Tu es un poil hors budget ceci dit. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Term Serv 16 ports
Le 25/06/15 08:05, Olivier Cochard-Labbé a écrit : Vu les prix pratiqués de ce type d'équipement plutôt simple je me suis lancé dans le DIY: - Une carte mère PC Engines APU (inclus 2 ports séries) + alim + SSD M-sata de 16G, environ 120€ - 2 cartes mini-PCIe 4 ports (+ 8 ports), environ 120€ pour les deux (je n'ai pas trouvé moins cher) - Un boitier rackable 1U en alu fait sur-mesure par une boite locale de découpe laser + pliage, environ 19€ l'unité (livré par 10) Je publierai le fichier DXF du boitier une fois que j'aurai validé le prototype. Je suis assez pour ce genre d'approche, d'autant que j'ai eu des petits soucis sur les différents opengear en ma possession, ce qui quand même ennuyeux vu que globalement il s'agit d'une simple appliance linux (avec une belle interface ok). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] SDN chez Google
Le 25/06/15 11:42, Julien Schafer a écrit : C'est bien cela qui me fait peur. Je n'irai pas jusqu'à dire qu'il n'y a jamais de bugs sur du matériel réseau, mais franchement ce que j'ai pu vivre et voir chez mes différents clients est de la rigolade au regard des problèmes que génèrent les OS, BDD, applis mal codées etc Si c'est pour appliquer le même modèle au monde des réseaux (qui globalement tourne bien) je suis pas sur du réel intérêt ;) Alors je n'ai pas exactement la même analyse. Il y a nécessairement plus de bugs sur l'ensemble d'un os/bdd/si au sens large car le spectre de couverture est beaucoup plus large. Mais dire aujourd'hui que les os réseaux tournent bien, c'est délicat, et ce n'est clairement pas mon avis. Et surtout c'est pour la grande majorité fermé, et donc tu es locké a tel ou tel constructeur. Alors qu'aujourd'hui on commence a avoir une belle majorité d'utilisation de technos opensources dans le reste de l'informatique, le réseau va devoir s'y mettre aussi. Donc personnellement cela ne me fait pas peur, bien au contraire. Évidement cela s'accompagnera de modèle plus simple que ce qui existe aujourd'hui dans le SDN. Et en ce sens je rejoins complétement l'avis de Michel. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] SDN chez Google
Le 25/06/15 13:17, Olivier MELWIG a écrit : Le tout est de bien conserver à l'esprit l'importance du réseau sous-jacent qui interconnecte tout cela et de pouvoir garder la visibilité des flux, voir des paquets qui y transitent pour être capable de troubleshooter tout incident qui se passe au-dessus, peu importe l'overlay utilisé. Tout à fait. C'est pour cela que je parlais de modèle simples, standards et si possible opensource. Mais tu as raison d'insister sur le point de la facilité du debug. C'est sur ce point que je préfère le modelè opensource que l'on peut trouver dans d'autres domaines d'informatiques, car on est généralement bloqué que par le temps que l'on veut y consacrer. Donc si vous avez des réflexions SDN ou du moins programmatiques pour automatiser vos opérations les plus fréquentes, gardez à l'esprit le besoin de pouvoir troubleshooter facilement la plomberie à travers votre orchestrateur/contrôleur ou non en cas de pb. Quoi qu'il arrive il y aura toujours besoin d'ingénieur qui savent comment marchent les technos sous-jacente, que ce soit en réseaux ou dans les autres domaines de l'informatique. Et heureusement pour nous :) Cdt, -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées
Le 26/06/15 12:40, Damien Fleuriot a écrit : Je trouve ça très réducteur, le propos sur le NAT. Avoir des machines en full IPv6 routable, c'est les exposer sur le net, et devoir les firewaller une par une. C'est chiant à maintenir, très chiant. Avoir du NAT (ou des reverse proxies), ça permet de coller un firewall en coupure, seul à avoir une IP routable, seul sur lequel un jeu de règles doit être maintenu. Je peux me tromper, vous avez peut-être des solutions alternatives, mais en ce qui me concerne des machines avec des IPv6 directement exposées sans NAT/RP c'est un accident qui attend d'arriver. Comme déjà évoqué, rien ne t’empêche de réserver une plage ipv6 que tu n'annonce pas dans la DFZ ou que tu drop en entrée de tes routeurs de bordure. Le Nat n'a jamais été conçu pour être un mécanisme de sécurité. Cela a crée un semblant de sécurité du fait des architectures mise en place pour contourner le manque d'ipv4. L'architecture courante étant tout les serveurs en rcf1918 derrière un firewall, ip publiques portés par le firewall et nat sélectif. Une architecture qui marche jusqu’à un certain point. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées
Le 26/06/15 13:05, Damien Fleuriot a écrit : Parce que pour que le firewall fasse office de point de coupure, encore faut-il que les bécannes qui sont derrière ne soient joignables que via ce dernier ? Ca semble un peu la base oui :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées
Le 29/06/15 11:17, Jérôme BERTHIER a écrit : Toutes les fonctionnalités de routage / filtrage sont disponibles pour les deux piles donc, si besoin, à part avoir à gérer un nouvel IGP (OSPFv3, RIPNG...) pour traiter IPv6, je ne vois pas la différence. Et quand tu utilises IS-IS même pas :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Open-Source Web-based IPAM
Le 29/06/15 14:12, nikolaii a écrit : Bonjour, je cherche à mettre en place un système de gestion d'adresses IP afin de gérer l'adressage de différents clients. J'ai vu les démos de NIPAP (http://nipap-demo.spritelink.net) et PHPIPAM (http://demo.phpipam.net/). GestióIP (http://www.gestioip.net/) semble également intéressant. Est-ce que certains ont essayé / utilisé l'un ou l'autre ? Quel est le plus pratique ? On utilise phpipam avec bonheur. Pas vu/eu de probleme avec. Cdt, -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Livebox et saloperie d'ALG MGCP
Le 30/06/15 10:57, David Ponzone a écrit : Non, la VOIP d’une Livebox GP utilise son port FXS et ils n’ont pas besoin d’un ALG dans ce cas puisque c’est la box qui construit le paquet SIP/MGCP/H323. Quand ils activent un ALG MGCP/SIP, c’est juste pour faire c…., soyons clair, puisque tu n’es pas censé brancher un poste IP derrière la box avec cette offre. Si je baisse mon niveau de parano, c’est peut-être juste pour avoir une conf homogène sur toute la gamme Livebox, mais j’ai quand même un doute parce que dans le cas précis, l’ALG MGCP s’amuse à remplacer l’adresse MAC du poste IP dans le RSIP (équivalent du REGISTER en SIP) par l’IP publique de la Livebox. Je vois mal comment ça peut être utile même à Orange, avec un client en IP non fixe. Non je penses que c'est juste les valeurs par défaut du CPE. J'ai côtoyé pas mal d’ingénierie CPE et c'est malheuresement pas trop le genre de truc sur lesquels ils s'attardent... -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Livebox et saloperie d'ALG MGCP
Le 30/06/15 17:31, Michel Luczak a écrit : Lorsque tu achètes des comptes/lignes SIP chez quelqu’un, c’est rare de pouvoir leur demander de changer de port… (j’imagine que c’est sa situation). Pas vraiment en relation mais il est triste qu'orange interdise toute inter opérabilité avec ses services voip... http://x0r.fr/blog/47 -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] - A vendre (bientôt) Catalyst WS-C6509-NEB-A
Hum généralement les 6500 commencent à être considérés comme du matériel fonctionnel, mais obsolète. De plus il y a en énormément en broke. Du coup on peut dire que cela rend service, mais que cela ne vaut pas grand chose, voire rien. (et qu'en général on accepte de s'en séparer pour un euro symbolique, surtout s'il n'y a pas de port 10G). Cdt, Le 07/07/15 14:50, Joël DEREFINKO a écrit : Bonjour la liste, On se prépare tout doucement à remplacer (horizon fin 2015) nos deux coreswitches à base de Catalyst 6500 (WS-C6509-NEB-A). Je viens donc vous sonder pour : --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: VRF et PPP
Le 29/07/15 06:25, Youssef Bengelloun-Zahr a écrit : Hello, Il peut y avoir toutes sortes de bonnes / mauvaises raisons à cela. Je peux comprendre le concept de dédier une interface pour le management. En revanche si on fait ça il faut pousser le concept jusqu'au bout, et donc dédier une vrf à cela. Mais une vrai vrf qui peut gérer tout le trafic de management. Hors donc à ma connaissance ce n'est pas encore tout à fait au point chez les différents constructeurs. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] OVH down ?
Le 29/07/15 22:22, Frederic Dhieux a écrit : Et OVH a souvent fait preuve d'une certaine transparence appréciable quand ils font des erreurs. Et sur ce coup la encore. Le commentaire d'octave est d'ailleurs assez savoureux. 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 :) +1 Cela me fait toujours rire les clients qui se plaignent que leurs services hébergés sur un seul serveur chez un hébergeur (lowcost ou pas) est down, et que c'est inadmissible. Si leurs services étaient si critique il faudrait peut etre penser à les redonder sérieusement. C'est à dire sur différents DCs et possiblement chez deux hébergeurs. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur intermediaire pour aiguiller le trafic vers différentes adsl
Le 31/07/15 15:59, Julien Escario a écrit : Marrant c'est exactement la logique qui fait que Cisco fait encore du chiffre. Y'en a pas d'autre. #trolldi Pas que. Certaines gammes cisco sont très bien. Maintenant sur ce besoin spécifique c'est vrai que n'importe quel petite box sous linux, bsd ferait aussi bien le boulot, voir mieux. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Petit routeur pour remplacer netscreen
Le remplaçant naturel du ns5 est le juniper srx100 (ou 110). Mais tu n'auras pas de wifi. Dépendant du besoin, n'importe quelle appliance x86 sous pfsense (ou autre) ferait bien l'affaire. Le 20/08/15 16:07, fr...@noend.fr a écrit : Bonjour à tous, Je cherche un Routeur avec au moins 4 RJ, avec un port WAN ( Quand je parle de port WAN, je pourrais parler d’une zone untrust ou Internet. Bref : là ou il y a souvent une sécu prédéfini) et le reste en LAN), faisant FW et permettant de faire du WiFI (pour remplacer un juniper Netscreen-5GT) que pourriez-vous me proposer sans aller dans des marques « PME » type netgear. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] CPE avec VRF
Le 26/08/15 18:40, eandre a écrit : Oui mais quand le BB est déjà full MPLS ? Sinon à l’ancienne : Chaque CPE = 2 tunnels GRE vers une concentration et marquage VRF pour chacun d’eux (donc on monte des tunnels à travers le MPLS) ou comment passer de A2A à du H&S :) Ou encore des tunnels l2tp. C'est encore plus pratique/homogène quand on opère déjà des LNS. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Probleme emailing avec free.fr et aliceadsl
Le 10/09/15 10:43, Arnaud Launay a écrit : Je propose une exclusion temporaire de 2 semaines du sieur Philippe. Arnaud (aujourd'hui, j'ai le droit). Un jeudredi ? PS : ça ping, et en v6 aussi. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Appliance filtrage URL/Firewall
Et bien, faire un dd de l'iso de pfsense vers une clé usb, ouvrir un boitier soekris et brancher la clé, faire le premier boot/install avec le câble serial quivabien, c'est très rapide :-) (et ça Juste Fonctionne™) Hors délai de livraison d'un soekris et configuration initiale du FW bien sûr. Plutôt prendre une alix apu. mais sinon +1 pour pfsense cela sera beaucoup plus simple et pérenne qu'une boiboite constructeur (dans ses tarifs). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] FRNOG 25.0 - BETA
Le 11/09/15 17:19, Romain Guichard a écrit : Je pense que vous surestimez grandement la volonté de la majorité des étudiants. La plupart se contentent très bien des polycopiés de cours et n'ont aucune envie d'aller approfondir certains sujets. Les ingés réseau formés n'auront pas tous la capacité/volonté de participer au FRnOG. Je partage ce constat. Mais cela s'explique assez facilement par le fait que ces métiers se sont démocratisés et ouvert aux plus grand nombres. D’où un certain nivellement par le bas. Il y a autant de bons éléments qui sortent qu'à notre époque, mais la proportion est plus faible. Pour résumé avant pour faire du système ou/et du réseau il fallait être vraiment passionné, maintenant c'est un métier comme un autre. Quant aux étudiants qui arrivent jusqu'au FRnOG (la plupart ignorent son existence, soyez en conscient), ce sont ceux qui ont à la fois eu la chance d'avoir choisi leur formation (meme à bac+3/4, certains ne savent pas trop où ils sont et pourquoi ils y sont), qui sont passionnés par leurs études et qui ont l'envie d'aller plus loin. Oui. Et je trouve cela bien. Même pour les gens qui font du réseaux, Frnog reste une communauté qui traite de sujet relativement spécifique (opérateur). Une majorité d'ingénieur réseaux ne vont pas trouver d'informations très pertinente pour eux sur cette liste. Cela ne remets pas en question le fait qu'il faille améliorer la passation de connaissance, ceux qui me connaisse savent que je déplore un peu l'état de celle ci dans le domaine. Mais je ne penses pas que ce rôle soit dévolu à Frnog. Du moins pas la liste. La communauté ? peut être. Je serais le premier a être partant pour la création d'un vrai livre opérationnel sur les réseaux. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Ip d'interco bgp
Le 14/09/15 21:08, Johann a écrit : Hello, Ca veut dire qu'ils ont moyen de connaître rapidement tes nouvelles IP d'interconnexion. Demande à tes transitaires de filtrer tout le trafic à DESTINATION des IP d'interconnexion (Uniquement. Pas du trafic qui passe) sauf leur routeur adjacent et le tien. Ou à minima le trafic ICMP/UDP pour bloquer tout type de traceroute sur la partie interco. Puis rechange d'IP d'interconnexion. Ca devrait te laisser un peu de répit sur ce vecteur d'attaque. On a fait cela avec un client qui était dans la même situation que toi. Bah oui c'est pas la mort de filtrer les ips d'interco(s), voir de pas les annoncer du tout dans la DFZ. Cela demande peut être un peu de re factoring sur le réseau de ton transitaire, mais bon franchement rien d'infaisable. Que cogent ne le fasse pas c'est compréhensible, ielo je suis plus dubitatif. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Ip d'interco bgp
Le 14/09/15 21:41, Johann a écrit : Ne pas annoncer ses IP d'interconnexion dans la DFZ demande à avoir un bloc 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). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Ip d'interco bgp
Le 15/09/15 00:51, Frederic Dhieux a écrit : 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. Oui tout à fait. Je n'avez pas mentionné dans mon premier mail mais c'est un des idée qui m'est venu a l'esprit. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Ip d'interco bgp / Solution IELO
Le 15/09/15 11:20, Cédric Tabary a écrit : On a décidé de griller le "last /22" que le RIPE nous a alloué pour les interco BGP à risque et on ne l'annoncera pas. On pourra éventuellement annoncer des plus spécifiques (/23 ou /24) si on en a besoin. Ca permet de ne pas en venir à des solutions du type interco en RFC1918, que je trouve vraiment sale. Yep voila. Pour le rfc1918 en temporaire ça passe (mais on sait tous que le temporaire est définitif et inversement). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Ip d'interco bgp
Ça peut servir à ce que ton client joigne son routeur depuis l'internet public en dehors de ses ips (en cas de problem d'annonce, par exemple). Tout à fait. Avec une default vers ton transitaire, cela peut faire un accès quand ton bgp est tout pété. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] overthebox
Le 25/09/15 10:57, Clément Breuil a écrit : Sinon il y a ceci => https://github.com/zehome/MLVPN Oui il existe de multiple solution pour faire de la pseudo agrégation de lien (lacp over tunnel, mlppp, etc...). Et mlvpn est une des solutions opensource les plus intégrés/simple. Rappelons que cela ne fonctionne correctement que si les différents liens agrégés sont fortement similaires (notamment en terme de latences), et que le débit agrégé est a peu près égal à 1.9 * la bp du lien le plus faible. Pour le dire autrement, agréger des liens *dsl du même fai, cela va plutôt bien marcher, en revanche avec de multiple fai (ou techno, genre cuivre) cela va être très moyen. Une autre question a se poser, c'est à ton vraiment besoin d'agréger ? une simple répartition sur les deux liens ne serait elle pas suffisante ? Et bien sur c'est reculer pour mieux sauter, la fibre étant la seule solution d'avenir :) Cdt, -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] overthebox
Sauf à utiliser Multipath TCP, qui est *précisément* fait pour fonctionner sur des technos très différentes (genre, VDSL + 3G). Je viens de regarder plus en détail la solution d'ovh. C'est une belle intégration d'un classique vpn over mptcp. Effectivement avec mptcp tu es moins impacté par la différence de latence, ceci dit de mes tests cela restait assez moche (openvpn-tcp over mptcp). L'utilisation d'un proxy socks transparent est assez maline. Ceci étant dit cela reste un très beau "bricolage" :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Isp full ipv6
Le 25/09/15 20:58, Olivier CALVANO a écrit : Mon soucis est plutôt simple, le réseau est composé de 3320 abonnés avec une box maison basé sur Linux. Jusqu'ici pas de soucis, le hic c'est que les adresses ipv4 doivent être rendu à l'opérateur qui fournissait l'accès internet car financièrement ce n'est pas viable (pas de bgp l'opérateur refuse, coût transit très chère et ils veulent profiter de changement de contrat pour intégrer un coût de location pour chaque IPv4) Du coup on réfléchi pour tout passer en IPv6 directement mais j'avoue ne pas tout maîtriser encore à ce niveau la. C'est une problématique intéressante et qui sera de plus en plus d'actualité. On peut résumer ton besoin en disant que tu doit fournir un accès internet sur tes liaisons access quelque soit la technologie. Visiblement l'option classique qui est de délivrer une ipv4 publique à chaque client/cpe est trop chère (je ne dirais jamais assez qu'il s'agit d'un cout à intégrer, 10 euros l'ip fixe (en moyenne) ce n'est pas un coup exorbitant pour un abonné, mais on a tellement été habitué a ne pas le prendre en compte...) Il te reste donc des solutions de nat, car malheureusement le contenu internet reste à 99% du v4. Et donc à faire du CGN (carrier grade nat, un gros mot pour juste dire que le nat s’effectue dans le core, et non coté cpe). Deux grand choix : soit tu décide de faire de l'ipv6 sur tes cpe, et donc tu te tourne vers du NAT64/DNS64, ou tu reste sur du v4 et tu fais du nat444. Les deux ont des avantages et des inconvénients, même si globalement je pense que rester sur du nat444 est plus simple (mais moins rigolote). Dans les deux cas il existe des appliances qui peuvent faire le boulot (A10 au hasard), ou bien tu peux faire ta solution custom. Dans tout les cas c'est faisable et déjà largement déployé, donc n’hésite pas sur si ta as besoin d'aide sur les détails. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] IP transit / Free et ou Orange
Le 30/09/15 16:09, Clement Cavadore a écrit : Je te conseillerais plutôt de te rabattre sur un des acteurs localement présent, et ayant une bonne connectivité vers Free/Orange, si c'est ce que tu recherches... mais ne sachant pas sur quel DC tu te trouves, je ne peux pas te conseiller qui que ce soit (mais j'imagine qu'ils ne manqueront pas de te contacter off liste :-)) Certainement. Ceci dit orange arrive maintenant à proposer du C3215E a des prix qui sont certes chers, mais pas non plus complétement déconnant. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
