Re: [FRnOG] [TECH] Ceph - priviégier petits ou gros disques?
Salut, Gros device = relativement peu d'IOPS, et gros impact en cas de panne d'un device Mais les gros devices permettent d'augmenter la densité Si tu ne prévois pas d'évoluer, les 500GB sont bien Sinon, les 2TB sont bien aussi Pour le modèle de flash, je te recommande les devices intel, nous avons beaucoup de 3610 en production "SSD" (ils ont des nouveaux modèles désormais) Cordialement, PS: https://www.frsag.org/ On 9/7/19 9:47 AM, Olivier Lange wrote: > Hello, > > Pour ceux qui ont de l'expériences de Ceph (avec Proxmox ou sans), j'ai une > question. > > J'ai des serveurs avec 6 emplacements disques 2,5. Je vais faire du full > SSD pour mon cluster Ceph. Je n'ai pas de très gros besoins d'espace. Je > privilégie la sécurité. > > Du coup, a votre avis, vaut-il mieux mettre 2 disques de 1,92To sur chaque > serveurs (donc 5x2x1,92To) ou vaut-il mieux mettre des disques plus petit > mais plus nombreux (style 5x6x480Go) ? Sans parler d'évolution par la > suite, ni de différence de stockage. > > Ma question est vraiment de savoir si, pour un espace identique, il vaut > mieux avoir 2 gros disques ou 6 petits disques par serveur? > > Merci. > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Questions sur Proxmox/Ceph
Ce n'est pas une idée de fou, c'est une idée de pauvre (dans le sens : très petite infrastructure) Si tu as même une volumétrie moyenne (suffisament de storage device pour nécessiter plusieurs VM), et plus de 2 hyperviseurs, tu as tout intérêt à avoir du matériel dédié On 7/25/19 3:24 PM, David Ponzone wrote: > Je me rends par contre compte que j’ai oublié de demander si certains avaient > osé l’archi avec Proxmox et Ceph sur les mêmes frontaux (plus de backend > donc). > Idée de fou ? Pire ? > > Merci > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le désastre Cloudflare / DQE / Verizon et les optimiseurs BGP
Les optimiseurs bgp, ce sont de mauvaises solutions à un vrai problème Le vrai problème : quand tu as X liens pourris vers une destination X, ta "qualité" n'est pas terrible (voir problématique) La fausse solution : faisont du vaudoo pour essayer de "choisir" le meilleur des mauvais liens La bonne solution : mettre en production de bons liens En effet, plusieurs possibilités: - soit tu te moques de la destination X (c'est un vague AS en biélorussie, OSEF). Dans ce cas, tu te moques aussi de la qualité que tu as vers cet AS. - soit la destination X est importante pour ton business, et du coup, au choix: - tu setup un PNI avec X - tu te connectes à un IX pour joindre X - tu te connectes à un transitaire qui est bon pour communiquer avec X Si tu deploies l'algorithme, il n'y a pas de place saine pour les "optimisateurs bgp" Au passage, n'oublions pas que l'AS qui n'a pas vocation de faire du réseau n'est pas supposé avoir de T1 : il va plutôt avoir une paire de T2 qui vont lui proposer un panel qualitatif de destination; Cordialement, On 7/2/19 3:25 PM, Francois Devienne wrote: > Bonjour FRNOG, > > Je me permets d’apporter quelques précisions au sujet des optimiseurs BGP. > > En avant propos, la notion d’optimisation BGP ne revêt pas une forme unique. > Elle était d’ailleurs souvent effectuée manuellement, de manière artisanale. > Quel est l’objectif de ces optimisations en général ? —> Influencer les > chemins entrant ou sortant afin : > - d’éviter la saturation d’une interface IX/peer ou transit connecté à > l’AS concerné, > - d'empêcher ou limiter des dépassements de CDR, en sollicitant une > capacité sous exploitée, > - de contourner un chemin qui perd des paquets (une congestion > franche), alors qu’un autre chemin, de meilleure qualité est disponible, > - de contourner un blackhole involontaire, > - d’améliorer les performances (RTD) avec une destination pour laquelle > BGP a choisi un chemin sous-optimal. > > Pour ce faire, la manoeuvre d’optimisation s’appuie sur des mesures de > performance et qualité des chemins ainsi que des collectes de données de > trafic et de topologie (Flows, SNMP, BGP), éventuellement travaillées par des > outils statistiques. > Les décisions de routage sont obtenues par l’exécution d’une politique de > routage, disons un algorithme dont la forme et les paramètres sont déterminés > par l’utilisateur. > Ensuite des configurations ou de nouvelles routes BGP sont envoyées aux > routeurs BGP à l’edge. > > On pourrait alors argumenter que BGP suffit largement et que l’Internet > marche très bien sans optimisation. Les statistiques montrent néanmoins que > cela est faux. Sur un échantillon d’une dizaine d’AS en France, > essentiellement connectées à des tiers 1 (deux transitaires au moins :-), > plus de 50% des décisions de BGP sont sous-optimales. Parfois pour des > différences négligeables, parfois pour quelques dizaines de millisecondes, ou > encore pour 5% de perte de paquets. BGP ne voyant naturellement ni le RTD ni > le packet loss end-to-end. Idem pour la gestion de capacité contractuelle ou > physique. > > Décrire le ROI d’un optimiseur BGP de façon absolue est néanmoins impossible. > Chaque AS écoule un trafic de typologie propre et exploite des connectivités > qui acheminent ces flux particuliers selon des paramètres et événements non > déterministes. > Néanmoins, certains AS pensent avoir des performances et une qualité > convenables parce qu’ils n’ont aucun outil de mesures fiable. La “logique” > étant alors “Tant que je n’ai pas l’impression que ça déconne, c’est > certainement que ça marche très bien”. > > Il existe aujourd’hui deux grandes familles de solutions “d’optimiseurs”. > - Fait-maison : un certain nombre de grands producteurs de contenus, > d’hébergeurs, de CDN ou d’opérateurs ont développé leurs propres solutions de > mesure et d’automatisation du routage. Elles implémentent entièrement ou > partiellement ce que font les solutions commerciales. Il s’agit alors de code > propriétaire ou souvent d’agrégats de briques open source notamment pour la > collecte d’échantillons de trafic. > - Commerciaux : principalement trois solutions aujourd’hui : > - Internap MIRO / FCP = assez confidentiel > - Noction IRP = celui incriminé dans ce problème > - Border 6 NSI (Expereo XCA-Edge) = C’est nous, pour enlever > toute ambiguité. Technologie Française ! > Ainsi, il n’existe aucune norme / RFC ou définition communément admise de la > façon dont ces optimisations doivent être faites. > Chacun fait donc comme bon lui semble et certains apprennent de leurs erreurs. > > L’exemple du problème cité ici montre en effet que certains optimiseurs > découpent les subnets en deux pour les rendre “plus spécifiques” et qu’ils > deviennent ainsi préférés dans la table BGP et la table de routage. > Si 8.8.8.0/24 est routé via transit “A” avec
Re: [FRnOG] [MISC] Adoption de nouveaux protocoles
Quelle importance ? La sécurisation du niveau applicatif en se basant sur la couche 4 (ou 3, pour ce que ça vaut) est risible et déficiente On 03/15/2019 09:23 AM, Thierry Chich wrote: > Je ne suis pas fan du NAT, mais il restera de toute façon, ne serait-ce > que pour les reverse-proxy. > > Ce qui est vraiment haïssable, ce sont ces protocoles merdiques avec des > ports dynamiques de partout et dans tous les sens. > > Et ça, IPv6 ou non, ça restera hyper-compliqué à sécuriser. > > Thierry --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Adoption de nouveaux protocoles
Il y a plus de 4 milliards de devices dans le monde en 2019 Tu peux gratter autant que tu veux, les 32 bits d'espaces ne sont pas suffisant (et le DoD & co n'a rien à voir avec ça) On 03/09/2019 05:32 AM, Michel Py wrote: > Si Apple et plein d'autres ne gaspillaient pas une classe A entière rien que > pour eux, si DoD n'avait pas le tiers de l'IPv4 mondial sans l'annoncer, si > les FAI établis n'avaient pas joué à l'épicier, si on avait transformé la > Classe E en unicast, si si si. Yàkà fokon. > > Michel. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Adoption de nouveaux protocoles
I lol'd Disposant d'un réseau "privé" causant à des réseaux "privés" d'autres boites -donc avec des plans d'adressages que je ne gère pas-, permet moi de glousser On 03/08/2019 03:17 AM, Michel Py wrote: > L'énorme avantage de NAT ce n'est pas tellement la vague sécurité que çà > apporte, mais l'assurance contre la renumérotation. > Michel. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Adoption de nouveaux protocoles
https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool À suivre .. Je suis surpris, personne ne semble avoir parlé du nat L'IPv6, c'est la liberté et la possibilité de ne pas avoir de nat Priceless, de mon point de vue Finalement, l'IPv6 n'intéresse que les gens compétents :) Les puristes, me dira-t-on, ceux qui ont l'amour du travail bien fait, ceux qui font du réseau et sont heureux de faire du réseau, et non pas un gros tas de dirty hack et autres contournements M'enfin, il est clair que ce n'est pas donné à tout le monde .. On 03/07/2019 01:59 AM, Michel Py wrote: > Plein de gens s'attendaient à une ruée vers l'or spéculative sur le marché de > l'IPv4, ce qui n'est pas arrivé. Le marché s'est un peu réchauffé l'année > dernière, mais il n'y a aucun signe de spéculation. Encore un autre FUD qui > s'avère ne pas arriver. > > Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering / net / web ...
On 04/02/2014 15:44, Raphael Maunier wrote: Non, mais WTF, tu crois vraiment que l'ado de 12 ans qui passe son temps a s'e'changer des sms mielleux avec son copain/copine a` envie de faire une session en console sur son tel ? Nan mais, tu es trop reste' dans ta cave ces derniers temps. Ils s'en fichent, et tre`s franchement, a` la maison, avec mes gamins quand son ipad / console plante : Have You Tried Turning It Off And On Again? http://www.youtube.com/watch?v=nn2FB1P_Mn8 Ben de'sespe`re pas, c,a montre juste que ton boulot d'e'ducateur est pas fini, t'es pas le seul et y'a pas de honte, mais ce n'est pas non plus une finalite' : tes gamins peuvent encore trouver la lumie`re; Et bon, aussi, ou est le mal dans faire du fric ? J'ai pas dit que c'e'tait mal : c'est la logique du commerc,ant. Mais le public n'a pas vocation a` se laisser re'duire au statut de consommateur ni a` accepter la restriction de sa liberte' de choix dans l'inte're^t du commerc,ant. Le gros soucis, c'est l'e'ducation. On vous a bassine' la tete que tout devait e^tre gratuit / libre ( linux, le peering, etc etc ). Nous sommes dans une socie'te' de consommation, il va falloir t'y faire, et l'accepter. C'est la vie. Quand tu visites un immeuble sur NYC, pour acce'der a l'e'tage X tu paie 20$, pour aller X+10 e'tages, c'est 20$+5, etc etc. Donc celui qui n'a pas les moyens voit presque la meme chose, et c'est comme c,a. Tu confonds payer plus pour avoir plus, et payer plus pour conserver la liberte' de choisir. Non, je parlais d'acheter en fonction de ces moyens, c'est tout. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Firewall DataCenter
Tu vas dire que pas un seul type de la liste ne va argumenter quant aux côtés éthiques du truc ? Mettre ce genre de produits qui drop à la volée engendre trop souvent les dérives suivantes : - limitation des libértés côtés cust (ex: bloquer des ports, drop du trafic port 80 qui n'est pas HTTP etc) - limitation de l'évolutivité d'Internet (ex: bloquer tout ce qui n'est pas TCP/UPD/IP, bloquer les paquets TCP avec une option que j'connais pas, bloquer l'HTTP avec une méthode que j'connais pas etc) C'est, à mes yeux, bien plus important que la guerre sur les moyens, non ? On 25/01/2014 00:35, Guillaume Barrot wrote: Question récurrente, posée environ tous les deux mois sur la liste. Je vais te résumer à la grosse les positions trollesques que tu vas avoir : ** discussion stérile sur firewalling c'est du niveau 3/4 vs meuh non c'est du niveau 7, UTM sa maman etc pendant environ 20-30 mails ** ** puis on invoque les trolls pro technos ** gna gna gna SRX gna gna CLI super cool et MPLS gna gna grouf grouf grouf Fortinet grouf grouf parce qu'ASA ah ah ah gna gna Fortinet c'est de la dreum, la CLI est pourrie gna gna gna grouf grouf Juniper m'en fous du MPLS sur mon firewall grouf grouf ** discussion stérile pendant 45 mails environ ** ** intervention d'un pro solution en train de trepasser (Checkpoint, Stonesoft, etc...) ** ki ki ki Firewall truc truc ? ki ki ki = atomisation de l'outrecuidant ** intervention d'un pro firewall opensource ** pouet pouet Pfsenso-Mikrotiko-Gentoo-over-x86 ? pouet pouet = double atomisation soyons serieux bordel et finalisation du lustrage par un point Godwin bien mérité. Tu finis avec mal aux yeux, des idées bien embrouillées, voire quelques envies de meurtres. Bref : 1- pose une sonde (serveur + snort), fais des stat (netflow est ton ami) 2- fais en un cahier des charges et un cahier de tests (fais toi ta matrice IMIX). Oublie pas de bien qualifier les usages que tu comptes en faire et les SLA que tu veux pouvoir offrir. 3- envoie ça aux fournisseurs 4- rencontre les et avec un couteau bien aiguisé sous la gorge, négocie des POC chez eux et du pret de matos 5- fais des labs et des tests (merci la virtualisation, quasiment tous les firewalls serieux ont une demo en VM downloadable directement sur le site = tests fonctionnels, test de l'API etc.) 6- si tu as un injecteur, vérifie les datasheets. Si t'en as pas, va faire des pocs chez les constructeurs. Si c'est trop long/compliqué = fais donc confiance aux Datasheets ou au Gartner (et pleure). Et fais toi ta propre opinion en fonction des tes besoins, du niveau des tes équipes, de tes habitudes (CLI, GUI, API) et du niveau de tes devs. Demande l'avis à une mailing list ... autant regarder le Gartner et choisir le point en haut à droite ! PS : Juniper ISG ? Tu veux pas installer un PIX non plus ??? Le 24 janvier 2014 12:23, Yoann THOMAS ytho...@openip.fr a écrit : Bonjour la liste, Je suis en plene réflexion sur l'implémentation de nouveau firewall en frontal de nos services cloud, dans ce cadre j'aurais souhaitez avoir vos avis et/ou retour d'expérience. Pour ma part aujourd'hui je suis sur les pistes suivantes : Brocade ADX Juniper ISG Cisco ASA (pas trop fan) Fortigate 3600 Merci d'avance pour vos retours. Yoann --- Liste de diffusion du FRnOG http://www.frnog.org/ -- UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things. – Doug Gwyn Trouve un travail qui te plaît et plus jamais tu ne travailleras Confucius Celui qui échange la liberté contre la sécurité ne mérite ni l'une ni l'autre et perdra les deux Thomas Jefferson signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] Le troll du vendredi par Michel
On 24/01/2014 11:07, Emmanuel Bourguin wrote: technic...@hahd.fr s'exprima en ces termes : Merci Michel. Comme beaucoup de gens j'aime vraiment pas les publicitaires, alors une startup publicitaire qui galère pour afficher sa pub de merde, c'est parfait! qu'elle mette la clé sous la porte et le plus vite sera le mieux. C'est difficile d'avoir du respect pour celles et ceux qui consacrent leur temps et leurs efforts à pourrir la vie des autres pour rentrer du pognon. On a beau être vendredi, c'est pas une raison pour se croire sur la page de commentaires du site du Figaro et dégueuler sa haine sans rien apporter de constructif. Si t'aime pas la pub, tu édites ton /etc/hosts ou tu installes AdBlock. Si tu souhaites à quelqu'un de se retrouver au chômdu c'est hors liste que ça se passe. Si tu as une réponse technique pertinente à lui apporter sans jugements sur son activité, là tu peut poster. Tu as un peu confondu les trois malheureusement. J'suis pareil, j'ai des problèmes à envoyer mes photos d'enfants nus aux freenautes. Quelqu'un a une solution à mon problème ? PS: merci de ne pas critiquer mes activités, ce n'est pas bien de vouloir me voir au chômage quand même, nahmého ! --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Interco BGP sur subnet RFC1918 : on en est arrivé là ?
Tien, fait-ça : mtr 81.28.194.51 On ne dois pas accepter de routes pour ces préfixes, ni même les forwarder dans la GRT Y'a une différence entre accepter des routes RFC1918, et utiliser des IP RFC1918. Dans le cas d'une session BGP, tu peux être connecté directement à ton peer; Et dans ce cas, l'utilisation d'IP RFC1918 me parait une bonne utilisation. Bon, j'avoue, il ne faut pas généraliser ce genre de choses (les traceroutes sont moches !); Utilisé avec parcimonie, cela ne me choque pas; -- UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things. – Doug Gwyn Trouve un travail qui te plaît et plus jamais tu ne travailleras Confucius Celui qui échange la liberté contre la sécurité ne mérite ni l'une ni l'autre et perdra les deux Thomas Jefferson On 20/11/2013 15:13, Baptiste Malguy wrote: En 2005, pour de l'accès simple par fibre, lors d'un déménagement, un opérateur dont le nom commence par C m'avait imposé un /30 d'interco similaire sur le nouveau site. Il y a combien de lettres dans le nom de ton opérateur ? :) --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
