Re: [FRnOG] [TECH] Quagga ou FRRouting ?
Bonjour à tous, Pour ma recherche (scientifiques) j’ai des besoins très pointus en dev/connaissance réseau/système etc. Et par expérience je trouve largement plus facilement des profils sachant faire cela « à Shanghai » ou à Pékin qu’en France. Alors que je trouve au plus la moitié des doigts d’une main des ingés en France sachant programmer en C/C++/python et qui puisse par exemple faire du DPDK+ TCAM+ implanter un algo de routage (oui c’est ce qu’on fait en recherche), j’ai une trentaine de candidats généralement en Chine et je peux me permettre le luxe de les faire travailler un an à un salaire chinois avant de décider de les faire venir en France pour un an dans le cadre d’une cotutelle de thèse ou de mémoire de mastère. Donc je plussoie ce que dis Guillaume, mais j’ajoute que ce genre d’animal rare se trouve de moins en moins en France, mais si vous avez accès à l’international ca se trouve … Bon, étant à l’université c’est plus facile pour moi d’avoir des contacts à l’international. Mais nos thésards veulent parfois rester ….. A+ Kv > Le 17 août 2018 à 10:37, Xavier Beaudouin a écrit : > > Salut Guillaume et la liste, > >> "Mais à te lire j'ai la très nette impression que tu cherche le dev qui >> sait tout faire >> mais que tu ne veux pas non plus le former a apprendre les choses qu'il ne >> connais pas. >> Ce qui est un mal assez français il me semble." >> >> Eh eh, perdu ;) >> Au contraire, perso, j'ai du bol j'ai un super associé qui dev super bien >> ET qui comprend bien la couche réseau. Et le top : il est ultra curieux. Et >> autonome. > > Et bien gardes-le car c'est rare. Mais avoue, à te lire, on pouvais penser > que tu cherchais des excuses au non développement de plein de choses. > >> Mais on en trouve finalement pas mal en France des comme ça. Et ils sont >> chers, certes, mais pas tant que ça. En tous cas, à côté d'un "business >> developper" , d'un "IOT and Big Data evangelist" ou autre "chef de projet >> transverse", c'est même gratuit. > > +1, tu fais donc partie des rares qui savent le prix d'une vrai compétence. > > Quand je disais "mal français", je pensais plus aux marchants de viandes > bien connus qui te placent un "expert" alors que c'est un stagiaire > >> Le problème c'est dans certaines boîtes (Junisco) on a pensé qu'on pouvait >> prendre du dev a pas cher à Mumbai, et que ça allait bien faire le job. Ok >> ils ont pas une bille en réseau, mais c'est un super centre de service, les >> mecs sont interchangeables parce qu'on a mis un million de dollars dans une >> super GED, donc ils vont documenter, et du coup, tout va aller bien mieux >> qu'avec nos barbus à sandales qui râlent, qui coûtent chers et qui ont des >> revendications. > > T'as aussi ceux qui prennent un boite "marque blanche" made in china et qui > collent une étiquette "" et qui après avouent que la "R" est a > Shanghai. > >> La règle est pourtant super simple : la compétence se paye et des fois >> l'argent n'est pas la monnaie attendue. >> >> Conclusion : qualité du code en chute libre chez Junisco, bugs en pagailles >> parce qu'on essaye à chaque fois de rajouter des features sans supprimer >> les vieilles (coucou le marketing qui dirige tout) etc... > > Pas que. Extreme Network est aussi dans mon collimateur, exemple sur certains > switches : > > snmp(bulk)walk -v2c -c COMMUNITY -Ln -Osq -m IP-MIB -M mibs:mibs/enterasys > udp:HOSTNAME:161 ipAddressIfIndex.ipv6 > > Qui fait reboot... > > Pratique... le case est ouvert depuis 2 mois, on attends qu'ils fixent leur > machin... Il y aurais peut-être une mise a jour en train d'être "compilée"... > > Ceci est un bel exemple de la qualité de code de certains équipementiers. > > Du coup je compte de plus en plus sur des outsiders et/ou de l'open source. > Et j'ai la même désagréable expérience vis a vis de juncisco. Par contre pour > le TAC et pour avoir qqn de compétant il faut ouvrir le ticket aux horaires > de la Californie, au moins on tombe pas sur un dérouleur de procédure pour > nains de jardin sur ectasie ... > > > /Xavier > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
Salut Guillaume et la liste, > "Mais à te lire j'ai la très nette impression que tu cherche le dev qui > sait tout faire > mais que tu ne veux pas non plus le former a apprendre les choses qu'il ne > connais pas. > Ce qui est un mal assez français il me semble." > > Eh eh, perdu ;) > Au contraire, perso, j'ai du bol j'ai un super associé qui dev super bien > ET qui comprend bien la couche réseau. Et le top : il est ultra curieux. Et > autonome. Et bien gardes-le car c'est rare. Mais avoue, à te lire, on pouvais penser que tu cherchais des excuses au non développement de plein de choses. > Mais on en trouve finalement pas mal en France des comme ça. Et ils sont > chers, certes, mais pas tant que ça. En tous cas, à côté d'un "business > developper" , d'un "IOT and Big Data evangelist" ou autre "chef de projet > transverse", c'est même gratuit. +1, tu fais donc partie des rares qui savent le prix d'une vrai compétence. Quand je disais "mal français", je pensais plus aux marchants de viandes bien connus qui te placent un "expert" alors que c'est un stagiaire > Le problème c'est dans certaines boîtes (Junisco) on a pensé qu'on pouvait > prendre du dev a pas cher à Mumbai, et que ça allait bien faire le job. Ok > ils ont pas une bille en réseau, mais c'est un super centre de service, les > mecs sont interchangeables parce qu'on a mis un million de dollars dans une > super GED, donc ils vont documenter, et du coup, tout va aller bien mieux > qu'avec nos barbus à sandales qui râlent, qui coûtent chers et qui ont des > revendications. T'as aussi ceux qui prennent un boite "marque blanche" made in china et qui collent une étiquette "" et qui après avouent que la "R" est a Shanghai. > La règle est pourtant super simple : la compétence se paye et des fois > l'argent n'est pas la monnaie attendue. > > Conclusion : qualité du code en chute libre chez Junisco, bugs en pagailles > parce qu'on essaye à chaque fois de rajouter des features sans supprimer > les vieilles (coucou le marketing qui dirige tout) etc... Pas que. Extreme Network est aussi dans mon collimateur, exemple sur certains switches : snmp(bulk)walk -v2c -c COMMUNITY -Ln -Osq -m IP-MIB -M mibs:mibs/enterasys udp:HOSTNAME:161 ipAddressIfIndex.ipv6 Qui fait reboot... Pratique... le case est ouvert depuis 2 mois, on attends qu'ils fixent leur machin... Il y aurais peut-être une mise a jour en train d'être "compilée"... Ceci est un bel exemple de la qualité de code de certains équipementiers. Du coup je compte de plus en plus sur des outsiders et/ou de l'open source. Et j'ai la même désagréable expérience vis a vis de juncisco. Par contre pour le TAC et pour avoir qqn de compétant il faut ouvrir le ticket aux horaires de la Californie, au moins on tombe pas sur un dérouleur de procédure pour nains de jardin sur ectasie ... /Xavier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
"Mais à te lire j'ai la très nette impression que tu cherche le dev qui sait tout faire mais que tu ne veux pas non plus le former a apprendre les choses qu'il ne connais pas. Ce qui est un mal assez français il me semble." Eh eh, perdu ;) Au contraire, perso, j'ai du bol j'ai un super associé qui dev super bien ET qui comprend bien la couche réseau. Et le top : il est ultra curieux. Et autonome. Mais on en trouve finalement pas mal en France des comme ça. Et ils sont chers, certes, mais pas tant que ça. En tous cas, à côté d'un "business developper" , d'un "IOT and Big Data evangelist" ou autre "chef de projet transverse", c'est même gratuit. Le problème c'est dans certaines boîtes (Junisco) on a pensé qu'on pouvait prendre du dev a pas cher à Mumbai, et que ça allait bien faire le job. Ok ils ont pas une bille en réseau, mais c'est un super centre de service, les mecs sont interchangeables parce qu'on a mis un million de dollars dans une super GED, donc ils vont documenter, et du coup, tout va aller bien mieux qu'avec nos barbus à sandales qui râlent, qui coûtent chers et qui ont des revendications. La règle est pourtant super simple : la compétence se paye et des fois l'argent n'est pas la monnaie attendue. Conclusion : qualité du code en chute libre chez Junisco, bugs en pagailles parce qu'on essaye à chaque fois de rajouter des features sans supprimer les vieilles (coucou le marketing qui dirige tout) etc... Le jeu. 16 août 2018 à 09:13, Xavier Beaudouin a écrit : > Hello Guillaume (et la liste), > > > " Pour le troll: Pour ISO, c'est malheureux... il suffirait de remplacer > par > > une couche de transport local (fe80::) IPv6 et ça deviendrait plus > simple." > > Et trouvez des dev C qui comprennent IPv6 : le défi ultime ! > > Wow... Entre les dev qui ont du mal a coder en C sur l'ISO (bon oky) > et ceux > qui ont aussi des pb en IPv6... Je sens qu'on un bel avenir... autant > revenir au > cobol peut-être ? > > Après si ces dev ont des problèmes, c'est peut-être que le processus de > recrutement > ou, dans le cas d'un projet opensource, que la communauté n'as pas assez > de gens > compétents ? > > Si sur l'ISO, je peux comprendre qu'on a quelques difficultés a comprendre > le biniou, > sur des protocoles réseaux, j'ai plutôt peur de la qualité du code sur > lequel tout > est basé. Est-ce que nos fondations sur du sable ? > > Après y a aussi de la formation qui peux être donnée a ces développeurs, > c'est pour > leur bien et celui du projet (opensource ou pas). > > Mais à te lire j'ai la très nette impression que tu cherche le dev qui > sait tout faire > mais que tu ne veux pas non plus le former a apprendre les choses qu'il ne > connais pas. > Ce qui est un mal assez français il me semble. > > Xavier > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
Pour l'isis il y a une stack opensource dans freerouter ( http://freerouter.nop.hu). C'est du java et ça m'a toujours rebuté, donc j'ai jamais testé, mais ça peut en intéresser certains. --- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
" Pour le troll: Pour ISO, c'est malheureux... il suffirait de remplacer par une couche de transport local (fe80::) IPv6 et ça deviendrait plus simple." Et trouvez des dev C qui comprennent IPv6 : le défi ultime ! J'ai connu des quetes AD qui partaient moins bien, mais franchement, ça se compte sur les doigts de la main. Le mer. 15 août 2018 à 20:45, Vincent Jardin a écrit : > Floodez > https://github.com/FRRouting/frr/issues > de vos retours sur la doc de ISIS, d'interop, d'usage, de perf, et ça > évoluera vite. > > @+ > Vincent > > Pour le troll: Pour ISO, c'est malheureux... il suffirait de remplacer par > une couche de transport local (fe80::) IPv6 et ça deviendrait plus simple. > > > > -- Cordialement, Guillaume BARROT --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
Floodez https://github.com/FRRouting/frr/issues de vos retours sur la doc de ISIS, d'interop, d'usage, de perf, et ça évoluera vite. @+ Vincent Pour le troll: Pour ISO, c'est malheureux... il suffirait de remplacer par une couche de transport local (fe80::) IPv6 et ça deviendrait plus simple. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
De l'aveu même de plusieurs sources coté fournisseurs (Vincent confirmera), ISIS en général, c'est compliqué car 1) c'est de l'ISO en dessous, et trouver des devs C qui comprennent l'IP c'est pas simple, alors qui comprennent l'ISO ... 2) ramené aux nombres de réseaux existants dans le monde, c'est le protocole IGP probablement le moins déployé _ je sais, moi le premier, j'allais dire "putain mais tous les SPs..." mais en fait, déjà c'est pas tous les SPs ou toutes les grosses boites GAFA and co, ensuite, même si c'était le cas, ça ne représente qu'un %age très faible des réseaux et des équipements dans le monde. Toutes les industries, les banques, etc c'est de l'OSPF, ou de l'EIGRP "parce que Cisco ils ont dit que ..." _ donc le plus complexe à tester en conditions réelles 3) du coup, s'amuser à tester les interops entre équipements là dessus, c'est aussi du défi ... 4) faut faire les tests de nonreg sur un proto supplémentaire = cher, compliqué (surtout qu'encore une fois c'est de l'ISO) 5) pas mal d'équipementier achètent clef en main une stack déjà toute faite (ex : ZebOS, 6windgate, etc.) du coup, si y a un bug, tout le monde se le prend. Donc perso, j'adhère, c'est de loin mon proto favori, mais c'est aussi le moins bien implémenté en général, sauf si vous avez des vieux VAX en Decnet, là oui, c'est propre... A priori, coté FRR c'est plus que correctement implémenté. J'attendrai juste un code un peu plus souple pour pouvoir créer des TLVs customs si on a envie (ah ah ah ...), genre on supprime isis_tlds.c +.h, et on les remplace par un directory isis_tlds.d avec un couple ".c" ".h" *par* tld, et un include à la racine ? Même remarque pour BGP d'ailleurs ... Je dis ça, je dis rien :D Le mer. 15 août 2018 à 08:11, Xavier Beaudouin a écrit : > Hello, > > (...) > > > Il y a un autre truc que je pourrais tester si c'était dispo sur ma > plate-forme > > : EIGRP. Ennui de taille : la plate-forme en question c'est pfsense ;-) > > J'ai installé le module FRR pour pfsense mais il a pas EIGRP. J'ai mis > RIPv2 (je > > sais, quelle horreur) pour apprendre les routes internes. > > Disons que dans un réseau que j'ai repris, j'ai vu de l'EIGRP, avec > quelques coup de > pute venant du protocole, j'ai été très content de virer ça pour y coller > de l'OSPF. > Ok OSPF c'est sale, mais y avais pas d'IS-IS sur les autres équipements. > > En parlant d'IS-IS c'est trop souvent le proto ouvert qui manque un peu > partout. Qui > a les même avantages que EIGRP sans trop les emmerdes. Donc quitte a virer > de l'OSPF > et du RIP, autant passer en IS-IS. > > > > Y'à plusieurs trucs pas clairs sur FRR/pfsense : aucun écran pour > configurer > > RIP, routed est dispo comme module (faudrait au moins dire que FRR c'est > > mieux), les routes RIP apprises par routed ne sont pas visibles, les > routes RIP > > apprises par FRR le sont mais elles apparaissent comme "Kernel routes". > > L'implementation sur pfsense m'as fait mal à la tête et surtout trop > limitée avec le > cliquodrome. Resultat j'ai mis un Edge Router X devant : plus de pb. > > Xavier > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Cordialement, Guillaume BARROT --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
Hello, (...) > Il y a un autre truc que je pourrais tester si c'était dispo sur ma > plate-forme > : EIGRP. Ennui de taille : la plate-forme en question c'est pfsense ;-) > J'ai installé le module FRR pour pfsense mais il a pas EIGRP. J'ai mis RIPv2 > (je > sais, quelle horreur) pour apprendre les routes internes. Disons que dans un réseau que j'ai repris, j'ai vu de l'EIGRP, avec quelques coup de pute venant du protocole, j'ai été très content de virer ça pour y coller de l'OSPF. Ok OSPF c'est sale, mais y avais pas d'IS-IS sur les autres équipements. En parlant d'IS-IS c'est trop souvent le proto ouvert qui manque un peu partout. Qui a les même avantages que EIGRP sans trop les emmerdes. Donc quitte a virer de l'OSPF et du RIP, autant passer en IS-IS. > Y'à plusieurs trucs pas clairs sur FRR/pfsense : aucun écran pour configurer > RIP, routed est dispo comme module (faudrait au moins dire que FRR c'est > mieux), les routes RIP apprises par routed ne sont pas visibles, les routes > RIP > apprises par FRR le sont mais elles apparaissent comme "Kernel routes". L'implementation sur pfsense m'as fait mal à la tête et surtout trop limitée avec le cliquodrome. Resultat j'ai mis un Edge Router X devant : plus de pb. Xavier --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Quagga ou FRRouting ?
> Vincent Jardin a écrit : > Pour RPKI: aucune idée, jamais vu en production. SVP, M. les sys/net-admin, > on a besoin de vos lumières et retours d'expérience sur FRR sur ce sujet. J'y travaille, c'est malheureusement pas en haut des priorités mais dès que j'ai quelque chose tu seras le premier à savoir. > Avoir le temps de développer ne veut pas dire qu'on a le temps de mettre en > production. L'un a besoin des retours de l'autre. Il y a un autre truc que je pourrais tester si c'était dispo sur ma plate-forme : EIGRP. Ennui de taille : la plate-forme en question c'est pfsense ;-) J'ai installé le module FRR pour pfsense mais il a pas EIGRP. J'ai mis RIPv2 (je sais, quelle horreur) pour apprendre les routes internes. Y'à plusieurs trucs pas clairs sur FRR/pfsense : aucun écran pour configurer RIP, routed est dispo comme module (faudrait au moins dire que FRR c'est mieux), les routes RIP apprises par routed ne sont pas visibles, les routes RIP apprises par FRR le sont mais elles apparaissent comme "Kernel routes". Que personne vienne me dire que "yàkà" configurer OSPF au lieu de RIPv2. Je sais que RIPv2 c'est de la merde, mais j'ai une config spéciale. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
Encore une fois, si tu l'utilises juste en Route Reflector, pas de soucis, mais si tu as du DPDK, dans lequel tu vas restocker tous les états de ton Linux, dont la table de routage, tu dimensionnes pas pareil (et c'est pas juste "ah ben x2, vu que DPDK aussi recopie les données", ça serait trop simple). Et désolé, je déploie plus dans ce mode là qu'en mode RR (une fois que t'en as posé 2/3, c'est pas le genre de truc que tu t'amuses à déployer tous les jours). Le mer. 8 août 2018 à 10:42, Hugues Voiturier a écrit : > Oui mais tu comprends, si tu mets pas 50x plus que nécessaire, t’es un > salaud qui sait gérer ses ressources... Visiblement certains ont des prix > sur la RAM... :P > > Sent from my iPad Pro > > > On 8 Aug 2018, at 10:24, Arnaud Launay wrote: > > > > Le Tue, Jul 31, 2018 at 11:36:14PM +0200, Guillaume Barrot a écrit: > >> Pour la RAM empiriquement je prévois 16Go par Full Route (1 > >> million de routes v4) > > > > Heu... ? > > > > Sur un quagga chargé ici: > > - 2 full routes > > - 2 ibgp full > > - du peering > > > > Et le tout doublé avec l'ipv6 (on va dire que c'est négligeable, > > avec ~ 55000 routes par full). > > > > -> Ca donne ça: > > > > qua3 ~ # LANG=C free > > totalusedfree shared buff/cache > available > > Mem:4054532 1893528 862148 660 1298856 > 1872752 > > Swap: 2298864 0 2298864 > > > > > > Donc je dirais, 1Go par full à tout casser... Prévoir 30% de plus > > (il n'y a "que" ~700k routes v4 actuellement) pour le million > > (sans vrf), donc allez, 1,5Go par full pour garder de la marge. > > > >Arnaud. > > > > > > --- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Cordialement, Guillaume BARROT --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
Oui mais tu comprends, si tu mets pas 50x plus que nécessaire, t’es un salaud qui sait gérer ses ressources... Visiblement certains ont des prix sur la RAM... :P Sent from my iPad Pro > On 8 Aug 2018, at 10:24, Arnaud Launay wrote: > > Le Tue, Jul 31, 2018 at 11:36:14PM +0200, Guillaume Barrot a écrit: >> Pour la RAM empiriquement je prévois 16Go par Full Route (1 >> million de routes v4) > > Heu... ? > > Sur un quagga chargé ici: > - 2 full routes > - 2 ibgp full > - du peering > > Et le tout doublé avec l'ipv6 (on va dire que c'est négligeable, > avec ~ 55000 routes par full). > > -> Ca donne ça: > > qua3 ~ # LANG=C free > totalusedfree shared buff/cache available > Mem:4054532 1893528 862148 660 1298856 > 1872752 > Swap: 2298864 0 2298864 > > > Donc je dirais, 1Go par full à tout casser... Prévoir 30% de plus > (il n'y a "que" ~700k routes v4 actuellement) pour le million > (sans vrf), donc allez, 1,5Go par full pour garder de la marge. > >Arnaud. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
Le Tue, Jul 31, 2018 at 11:36:14PM +0200, Guillaume Barrot a écrit: > Pour la RAM empiriquement je prévois 16Go par Full Route (1 > million de routes v4) Heu... ? Sur un quagga chargé ici: - 2 full routes - 2 ibgp full - du peering Et le tout doublé avec l'ipv6 (on va dire que c'est négligeable, avec ~ 55000 routes par full). -> Ca donne ça: qua3 ~ # LANG=C free totalusedfree shared buff/cache available Mem:4054532 1893528 862148 660 1298856 1872752 Swap: 2298864 0 2298864 Donc je dirais, 1Go par full à tout casser... Prévoir 30% de plus (il n'y a "que" ~700k routes v4 actuellement) pour le million (sans vrf), donc allez, 1,5Go par full pour garder de la marge. Arnaud. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
" > Hugues Voiturier a écrit : > Pour rester dans des proportions réalistes (on n’a pas tous uniquement des VM à 16Go de RAM), Oui, il y a des gens avec trop de sous ici :P" Ah ben désolé de ne pas m'inscrire dans la tradition séculaire du Frnog en montant des infras en bois de cagette, hein ! :D Sinon, petit correctif, mais je ne déploie pas de FRR hors contexte DPDK, donc forcément, niveau RAM, DPDK consomme aussi, et par le jeu des réplications d'états on double facilement la quantité de RAM. Après effectivement, je ne commande que des barettes 16Go, et je prefère prévoir large sur mes routeurs softs, car la RAM ne sert pas que à stocker la full route. La douce soirée, Le mer. 1 août 2018 à 06:46, Michel Py a écrit : > > Hugues Voiturier a écrit : > > Pour rester dans des proportions réalistes (on n’a pas tous uniquement > des VM à 16Go de RAM), > > Oui, il y a des gens avec trop de sous ici :P > > > j’ai une machine avec deux Full, 885Mo d’occupés. J’ai mis 2Go, pas trop > inquiet. > > Merci, çà semble raisonnable. > > Le truc qui me chagrine un peu dans le biniou, c'est que j'avais > l'intention de mettre et FRR et le RPKI validator dans la même machine > physique (pour commencer); tout le monde me dit que le validator de chez > RIPE il est sympa et il marche, mais les mêmes disent aussi qu'il est basé > sur Java et que question d'économiser la mémoire c'est pas top. > > > Entre deux maux, il faut choisir le moindre. Utiliser Java, ou laisser les > détournements de préfixes dans la DFZ ? > Hmm, choix difficile ;-) > > > Michel. > > -- Cordialement, Guillaume BARROT --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Quagga ou FRRouting ?
> Hugues Voiturier a écrit : > Pour rester dans des proportions réalistes (on n’a pas tous uniquement des VM > à 16Go de RAM), Oui, il y a des gens avec trop de sous ici :P > j’ai une machine avec deux Full, 885Mo d’occupés. J’ai mis 2Go, pas trop > inquiet. Merci, çà semble raisonnable. Le truc qui me chagrine un peu dans le biniou, c'est que j'avais l'intention de mettre et FRR et le RPKI validator dans la même machine physique (pour commencer); tout le monde me dit que le validator de chez RIPE il est sympa et il marche, mais les mêmes disent aussi qu'il est basé sur Java et que question d'économiser la mémoire c'est pas top. Entre deux maux, il faut choisir le moindre. Utiliser Java, ou laisser les détournements de préfixes dans la DFZ ? Hmm, choix difficile ;-) Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
Hello, Pour rester dans des proportions réalistes (on n’a pas tous uniquement des VM à 16Go de RAM), j’ai une machine avec deux Full, 885Mo d’occupés. J’ai mis 2Go, pas trop inquiet. Hugues AS57199 - AS50628 > On 1 Aug 2018, at 00:39, Michel Py wrote: > >> Guillaume Barrot a écrit : >> Pour la RAM empiriquement je prévois 16Go par Full Route (1 million de >> routes v4) > > Heureusement que çà vaut pas cher ;-) sur Cisco je compte 1Go par full view. > Heureusement d'ailleurs, vu que j'en ai un avec 2Go, j'ai encore quelques > années devant moi mais pas l'éternité. Je sais même pas combien de mémoire > j'ai dans le serveur de récup dont je vais me servir. > >> Vincent Jardin a écrit : >> Comme Guillaume, je confirme qu'il faut toujours privilégier les Ubuntu LTS >> pour du réseau : > > Merci, c'est bon à savoir. Ubuntu 18.04.1 LTS çà sera; s'il y a des trucs à > savoir pour FRR merci de me le faire savoir. Michel est bourrin : mets la clé > USB et appuie sur "Retour" jusqu'à ce que çà soit fini. > > >> Pour RPKI: aucune idée, jamais vu en production. > > L'objectif de ce machin est uniquement RPKI. Je sais pas si je vais le mettre > en prod tout de suite mais çà finira au moins dans le CBBC. RPKI il y a un > état supplémentaire (valid/unknown/invalid) donc faut s'attendre à ce que çà > bouffe plus de mémoire, combien eh bien on en discutera quand çà marchera. > > Michel. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Quagga ou FRRouting ?
> Guillaume Barrot a écrit : > Pour la RAM empiriquement je prévois 16Go par Full Route (1 million de routes > v4) Heureusement que çà vaut pas cher ;-) sur Cisco je compte 1Go par full view. Heureusement d'ailleurs, vu que j'en ai un avec 2Go, j'ai encore quelques années devant moi mais pas l'éternité. Je sais même pas combien de mémoire j'ai dans le serveur de récup dont je vais me servir. > Vincent Jardin a écrit : > Comme Guillaume, je confirme qu'il faut toujours privilégier les Ubuntu LTS > pour du réseau : Merci, c'est bon à savoir. Ubuntu 18.04.1 LTS çà sera; s'il y a des trucs à savoir pour FRR merci de me le faire savoir. Michel est bourrin : mets la clé USB et appuie sur "Retour" jusqu'à ce que çà soit fini. > Pour RPKI: aucune idée, jamais vu en production. L'objectif de ce machin est uniquement RPKI. Je sais pas si je vais le mettre en prod tout de suite mais çà finira au moins dans le CBBC. RPKI il y a un état supplémentaire (valid/unknown/invalid) donc faut s'attendre à ce que çà bouffe plus de mémoire, combien eh bien on en discutera quand çà marchera. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
Comme Guillaume, je confirme qu'il faut toujours privilégier les Ubuntu LTS pour du réseau : - car Ubuntu permet d'avoir des kernel récents avec la possibilité de rester up-to-date (indispensable car FRRouting aime bien tous les derniers fixes Netlink voire même il contribue à des fixes/évolutions upstream ; MPLS, VXLAN, netns/VRF). - packages utilisés par les développeurs communautaire. Pour la mémoire, 16Go OK. Cette question sur la mémoire semble venir du fond des temps. Pour RPKI: aucune idée, jamais vu en production. SVP, M. les sys/net-admin, on a besoin de vos lumières et retours d'expérience sur FRR sur ce sujet. Avoir le temps de développer ne veut pas dire qu'on a le temps de mettre en production. L'un a besoin des retours de l'autre. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
Salut Michel, Ubuntu est la plateforme de référence dans les tests de FRR. Je te confirme c'est stable, y compris quand on upgrade. Si pas déjà fait, jette un oeil à MAAS et Juju (notamment Google Juju + DPDK), ça devrait finir de te convaincre. Pour la RAM empiriquement je prévois 16Go par Full Route (1 million de routes v4) dans une VRF (overhead de ~20%). Ça tourne sûrement dans moins en réalité mais en 2018 je ne sais plus approvisionner de la RAM en dessous de 16Go perso. Si tu n'es pas au taquet financièrement n'hésite pas à partir sur 2 x 32 Go en RDIMM. Fuir les barrettes LRDIMM (64Go par ex) qui ont une latence quasiment dix fois supérieure selon les marques. Évidemment, pas de UDIMM mais là encore, on est en 2018. Si tu as deux procs, n'hésite pas à prendre 4 x 16Go repartis sur l'ensemble des canaux pour maximiser la perf en RAM. Je laisse Vincent ou Bortzman répondre sur RPKI, pas assez de recul la dessus. À+ Le mar. 31 juil. 2018 à 19:01, Michel Py a écrit : > > Vincent Jardin a écrit : > > FRRouting est la suite logique avec une communauté qui est ouverte à > tous > > types de contributions, donc plus large. Nous voulons juste que ça > avance > > vite, même s'il y a des risques. Pour l'instant FRRouting trace ,) > > Merci à tous ceux qui ont répondu, j'étais sur la même longueur d'onde > aussi. > > Vincent, > > - Est-ce qu'il y a un OS préféré ou est-ce que c'est vraiment agnostique ? > Je penche pour CentOS parce que c'est celui que je connais le mieux mais je > suis minable avec tous. > > - Combien de mémoire pour 2 full feeds avec 2 millions de routes chacun et > Origin Validation ? (je prévois pour le futur ;-) > > - Tu vois des problèmes particuliers à faire tourner un validateur RPKI > sur la même machine (serveur de routes, pas pour pousser du paquet). > > - Quel validateur RPKI ? A priori je me tourne vers celui de RIPE parce > que c'est celui qui a la peinture la plus sèche, mais j'écoute les avis. > > Merci, > > Michel. > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Quagga ou FRRouting ?
> Vincent Jardin a écrit : > FRRouting est la suite logique avec une communauté qui est ouverte à tous > types de contributions, donc plus large. Nous voulons juste que ça avance > vite, même s'il y a des risques. Pour l'instant FRRouting trace ,) Merci à tous ceux qui ont répondu, j'étais sur la même longueur d'onde aussi. Vincent, - Est-ce qu'il y a un OS préféré ou est-ce que c'est vraiment agnostique ? Je penche pour CentOS parce que c'est celui que je connais le mieux mais je suis minable avec tous. - Combien de mémoire pour 2 full feeds avec 2 millions de routes chacun et Origin Validation ? (je prévois pour le futur ;-) - Tu vois des problèmes particuliers à faire tourner un validateur RPKI sur la même machine (serveur de routes, pas pour pousser du paquet). - Quel validateur RPKI ? A priori je me tourne vers celui de RIPE parce que c'est celui qui a la peinture la plus sèche, mais j'écoute les avis. Merci, Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
Quagga était nécessaire car l'arbre CVS de Zebra était fermé : les committers ne prenaient aucun patch. Paul et moi étions donc parti sur un fork. Quagga avança sur cette dynamique mais avec peu de structure communautaire donc difficile à bouger. FRRouting est la suite logique avec une communauté qui est ouverte à tous types de contributions, donc plus large. Nous voulons juste que ça avance vite, même s'il y a des risques. Pour l'instant FRRouting trace ,) Le but ultime sera que les draft IETF des protocoles soient basés sur FRRouting. Je sais que beaucoup de patchs privés ont été faits sur Quagga. Bref oubliez les ils vont devenir caducs sur FRRouting. Idéalement envoyez des pull request. git sera votre guide... @+ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
Le Mon, Jul 30, 2018 at 10:28:27PM +, Michel Py [mic...@arneill-py.sacramento.ca.us] a écrit: > Bonjour à tous, > > J'ai bientôt besoin de monter un serveur de routes, et o suprême > insulte la syntaxe proche de Cisco est une nécessité donc pas de BIRD > (dommage, j'aime bien leur looking glass). > Quagga ou FRRouting ? j'ai mon avis mais j'aimerais bien savoir ce que > la liste en pense. Comme en son temps Quagga, par son dynamisme, avait supplanté Zebra, je pense que FRRouting est devenu l'héritier de fait de Quagga. -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
Le 31 juillet 2018 à 00:28, Michel Py
a écrit :
> J'ai bientôt besoin de monter un serveur de routes, et o suprême insulte la
> syntaxe proche de Cisco est une nécessité donc pas de BIRD (dommage, j'aime
> bien leur looking glass).
> Quagga ou FRRouting ? j'ai mon avis mais j'aimerais bien savoir ce que la
> liste en pense.
Si tu peux faire tourner un openbsd, openbgpd est très bien aussi. La
syntaxe de la conf n'est pas cisco-like mais la cli est plus "show ip
bgp summary" que "show protocol all", et le looking glass fourni dans
base fonctionne out-of-the-box avec httpd et letsencrypt sans efforts.
Voir https://lg.as7012.net pour ce que ça donne par exemple. Et c'est
utilisable en cli aussi, ssh://rviews:rvi...@lg.as7012.net. Voir
bgplg(8) et bgplgsh(8).
OpenBGPD est l'autre daemon supporté par arouteserver, et a une très
bonne intégration avec le système comme par exemple avec pf ('match
from group internal community $as:666 set pftable ').
Les problèmes de performance rencontrés par le passé par OpenBGPD sont
normalement réglés, mais entre temps bird est passé par là, et bgpd
n'est plus autant utilisé qu'avant. (mais au moins il y a de la
diversité !).
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] Quagga ou FRRouting ?
❦ 30 juillet 2018 22:28 GMT, Michel Py : > J'ai bientôt besoin de monter un serveur de routes, et o suprême > insulte la syntaxe proche de Cisco est une nécessité donc pas de BIRD > (dommage, j'aime bien leur looking glass). > Quagga ou FRRouting ? j'ai mon avis mais j'aimerais bien savoir ce que > la liste en pense. FRRouting. Il y a peu de débat, Quagga est quasi-mort. Pour un serveur de routes, il est dommage de se couper de la flexibilité d'un BIRD. Selon l'usage, regarde ce que sait faire ARouteServer pour générer la configuration. -- Make sure every module hides something. - The Elements of Programming Style (Kernighan & Plauger) --- Liste de diffusion du FRnOG http://www.frnog.org/
