Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
Bonjour, Juste une petite question concernant le choix d'un constructeur. Comment faire pour choisir le matos quand les tables de routage en IPv4 sont enormes et que l'IPv6 pointe son nez. Il me semble que les cartes supportant cela en hardware sont relativement onereuseset que nous ne savons pas si les dites cartes tiendront 1,2,3 ans. Peut être qu'une solution mixte est envisageable pour certaines societes afin de ne pas faire exploser les budgets. Fabien On 3 nov. 2012, at 10:27, David Ramahefason r...@netfacile.net wrote: Bonjour, J'ai fait tourner un ISP pendant 4 ans sur du Gated (NetBSD puis FBSD) puis un autre sur Quagga sans problème lié au soft. A l'époque le problème venait plutôt du faible choix des interfaces disponible. C'est possible mais j'en suis revenu :) à maintenir/faire évoluer je préfère avoir du constructeur mais ça peut être un moyen de démarrer une activité si on a pas les sous à mettre de suite dans du gros matériel (quoique maintenant faiut voir avec les PC actuels ce que l'on peut faire). Ensuite pour en revenir à la question principale, je suis de l'avis de Raphael: Keep it Simple, Murphy est déjà assez chiant comme ça :D Bon Week End Le 3 novembre 2012 08:58, Raphaël Maunier raphael.maun...@jaguar-network.com a écrit : On 3 nov. 2012, at 02:42, Manuel Guesdon ml+fr...@oxymium.net wrote: On Fri, 2 Nov 2012 23:01:42 +0100 Raphaël Maunier raphael.maun...@jaguar-network.com wrote: | On 2 nov. 2012, at 19:46, Laurent CARON lca...@unix-scripts.info wrote: | Je ne suis pas d'accord avec toi sur ce point. Si pour une PME ce point est critique, il y a toujours une solution autre que le Linux supporté par personne Oh, on doit trouver du support commercial dessus Oui, on doit ... Tu peux passer un coup de fil à ton opérateur, je ne suis pas certain qu'il te débug ton routeur soft | C'est justement la le pb. Tu ne sais pas ce que ce patch a comme autre implication. Hum, au moins tu as le sources (apres faut avoir les compétences). Combien de mecs qui l'installent savent lire un code source ? X% des gens maîtrisent les fichiers de conf sans comprendre le protocole, Y% des gens seront incapable de débug en cas de soucis car ils n'auront pas la maîtrise des fondamentaux. Des fois, c'est le linux/UNIX qui déconne et pas le soft de routage et la... C'est le drame Les solution cisco/machin/truc c'est la même chose sans les sources. En gros tu esperes que les gens qui ont pondu le truc soient compétents et motivés et tu prie pour que ca fixe effectivement le problème, qu'il n'y ait pas d'effet de bord etc. Oui, mais je préfère encore travailler avec un matos ou y a des équipes dédiées qui bossent sur la résolution des bugs que d'attendre qu'un mec dans sa cave fixe le pb du code qu'il a pondu et qui est super populaire. | Un opérateur ne tourne pas le dernier Junos ou Ios. Il attend généralement la 3 eme version du train dans lequel il souhaite aller. Pareil pour tout. Je ne pense pas qu'il y ait beaucoup d'allumés qui mettent en prod direct sans test ni rien une version x.0.0 ni sur des routeurs ni sur de serveurs... Heu Apt-get update, dist-upgrade ... Je suis sur que la plupart tourne les dernières versions :) | Chez les constructeurs de routeurs, tu as plusieurs niveau de support et d'escalade qui est fonction de ton type de maintenance, de ton parc installé et de la visibilité que tu apportes sur le marché. Chez Juniper par exemple ( c'est ce que je connais ), tu as ce mode de fonctionnement, et tu es capable d'avoir un mec en ligne en moins de 45 minutes qui te donnera des commandes à taper en CLI Shell qui tape directement l'Asic pour réparer ton bousin si jamais c'est un bug avéré. Ensuite, les dev bossent sur un bugfix. | Mais oui, je te l'accorde, ce n'est pas gratuit ... J'aimerais bien savoir pour 2 'petits' Cicsco/Juniper/Brocade (petits mais du genre qui fait ce que demandé par Simon: bgp co) combien ca coute en achat+support annuel pour avoir en moins de 45mn un gars qui te fait réparer ton bousin en cli sur le champs :-) Ça dépend du matos, ça peut aller de qq centaines d'euros pour les tout petits routeurs à qq milliers d'euros pour les gros routeurs backbone. Mais c'est vrai que ca peut servir: si ma mémoire est bonne il y a un an quasi pile poil [ld]es Juniper avait connu un petit bug :-) Il faut compter un bug majeur visible tous les deux ans chez tous les constructeurs :) Des bugs, ils en ont tous les jours et des trucs bien marrant des fois. Et comme le disait Laurent des fois, la résolution c'est : alors il y a un bug Mpls sur cett version, pour le résoudre ... Désactivez Mpls Et la on dit Merci monsieur, et on le traite de toute sorte de nom d'oiseaux en lisant la doc et tout le monde pensera que tu as le syndrome de tourette :) Manuel --
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
Hello Je conçois que dans le cas d'un opérateur il ne soit pas envisageable de gérer des routeurs soft (pour quelque raison que ça soit: fiabilité, gestion des révisions, hardware hétéroclyte, ...), mais dans le cas de $PME qui souhaite avoir une solution fiable et peu coûteuse, le jeu en vaut la chandelle. Je ne suis pas d'accord avec toi sur ce point. Si pour une PME ce point est critique, il y a toujours une solution autre que le Linux supporté par personne et qui en cas de soucis pourra avoir des conséquences plus désastreuses que les X k€ économisés au début de l'aventure. Donc, bien souvent le jeu n'en vaut pas la chandelle :) Heu ça dépend. Evidement savoir entretenir un routeur soft coute plus d'argent (=temps) que un juniper, Cisco ou Brocade (quoi que sur le dernier, j'ai un doute par rapport a mon expérience personnelle). Le support de certains logiciels libres (quoique sans avoir aucune garantie d'un éditeur/construccteur derrière) n'a rien à envier (parfois la situation est même inverse) à certains editeurs/constructeurs. Lorsque tu vois que tes sessions BGP flappent, que tu poste un message sur la liste misc (OpenBSD dans mon cas) et que 45minutes plus tard tu as obtenu un patch corrigeant le problème...chapeau. C'est justement la le pb. Tu ne sais pas ce que ce patch a comme autre implication. Heu... Je sens le troll velu... Pour avoir eu l'expérience a Claudio (autheur de openbgpd), ce gars est très réactif et quand tu as un patch qui est un diff de bgpd.c... Tu sais que l'implication du patche est... pour bgp. Alors que jinstall-12.1-R2.4-export.tgz (600Mo), tu es très sûr de ce qui a été changé (ou pas) dans ce JunOS. Sans compter le support : j'ai découvert ce probleme, support : ah bon ?, 1h passe : tu peux essayer cette release?... Vécu sur pas mal de constructeurs (au moins les 3 du début de mail)... Un opérateur ne tourne pas le dernier Junos ou Ios. Il attend généralement la 3 eme version du train dans lequel il souhaite aller. Les rares cas ou un opérateur doit le faire c'est : - Support de nouvelles cartes : les constructeurs nous pipeautent depuis des années en disant : Bah non, dans votre train actuel, c'est imposiibllle de rajouter le support de votre carte. Généralement, on appuie sur le bullshit button, mais sauf si tu es Verizon ou NTT ou un très gros, tu aura juste l'effet du bouton et donc, t'es bien barré pour un upgrade. - Support d'un nouveau protocole - bug vraiment mais vraiment violent qui ne peut pas être fixé avec une release de maintenance. #define violent ? par ce ... des bugs violent j'en ai eu... mais ils étaient violent pour moi (pas pour les autres). Des exemples de ce genre j'en ai des cartons entier (baie dell MD1200i qui n'a plus aucun volume au reboot. le support dell te dit restore from backups)... justement, c'est la mon propos :) les fournisseurs de HW serveurs ont les pires supports de la planète ! Les mecs ils optimisent rien, et ne savent pas faire de débug Pour dell (ou hp) même remarque que pour toi. D'ailleurs une des raisons pour lesquelles je préfère supermicro (ok y a pas de support mais du spare on site c'est toujours 1000 fois plus efficace qu'une GTR qui fait ce qu'elle veux). C'est comme tout, il faut s'y mettre, consacrer du temps, faire des tests, ... Sur la prod, tu ne fais pas de tests hein :) Des fois on n'as pas le temps... Tu sais le commercial qui pousse, ou encore nos amis les constructeurs qui changent silencieusement le hardware (par ex... la marque qui commence par D...). Donc tu testes, tu valide et puis 3 mois plus tard: tiens ? pourquoi j'ai pas le même comportement Xavier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
On 2 nov. 2012, at 23:01, Raphaël Maunier raphael.maun...@jaguar-network.com wrote: On 2 nov. 2012, at 19:46, Laurent CARON lca...@unix-scripts.info wrote: On Fri, Nov 02, 2012 at 05:36:39PM +0100, Raphaël Maunier wrote: Je conçois que dans le cas d'un opérateur il ne soit pas envisageable de gérer des routeurs soft (pour quelque raison que ça soit: fiabilité, gestion des révisions, hardware hétéroclyte, ...), mais dans le cas de $PME qui souhaite avoir une solution fiable et peu coûteuse, le jeu en vaut la chandelle. Je ne suis pas d'accord avec toi sur ce point. Si pour une PME ce point est critique, il y a toujours une solution autre que le Linux supporté par personne et qui en cas de soucis pourra avoir des conséquences plus désastreuses que les X k€ économisés au début de l'aventure. Donc, bien souvent le jeu n'en vaut pas la chandelle :) La PME en question n'a généralement pas les moyens de se payer un routeur dit hardware, donc, c'est pas vraiment le sujet Quand au linux supporté par personne c'est un non sens. Avoir la possibilité de payer un fournisseur de linux commercial pour pouvoir lui brailler dessus quand ca fonctionne pas, c'est une problématique de DSI de grosse boite, qui ne veux surtout pas savoir comment ça fonctionne. Quand a la possibilité de faire des procès pour éventuellement récupérer des dommages et intérêts, c'est tout autant hors sujet quand on parle de vraie PME... Bref, va te falloir apprendre la réalité des PME... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
Bonjour Fabien, On 03/11/2012 10:38, Fabien Delmotte wrote: Juste une petite question concernant le choix d'un constructeur. Comment faire pour choisir le matos quand les tables de routage en IPv4 sont enormes et que l'IPv6 pointe son nez. Il me semble que les cartes supportant cela en hardware sont relativement onereuseset que nous ne savons pas si les dites cartes tiendront 1,2,3 ans. Les petits routeurs d'entreprise, typiquement ce dont on parle là c'est du ISR-G2 ou 7200, à la rigueur ASR1001 chez Cisco, ou du SRX chez Juniper. Ces plate-formes (à l'exception de l'ASR) sont 100% soft, donc pas de souci avec le nombre de routes tant qu'il y a de la RAM. Pour en arriver à du routage matériel, tu es sur des besoins qui justifient des budgets qui ne justifient plus de se prendre la tête avec autant de détail ou de bidouillage : une paire de naimix 80 et c'est réglé. Ou bien, moins cher (du niveau d'un ASR) : CER2024 de chez Brocade. Peut être qu'une solution mixte est envisageable pour certaines societes afin de ne pas faire exploser les budgets. Là on va te répondre qu'une société n'a rien à foutre d'une full view. Une default + le 21 suffit et est déjà sur-dimensionnée dans la plupart des cas. La full view en RIB sert à fournir du transit ou à faire des stats drôles, la full view en FIB sert à optimiser ton routage au poil de fourmi près. Il y a donc deux approches : soit on monte des setups plus modestes quand on est pas assez fortunés pour jouer au grozopérateur, soit on rajoute des couches de bricolage qui feront hurler Raphaël et quelques autres puristes du chan qui ont probablement oublié leurs débuts. -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
On 03/11/2012 13:10, Raphaël Jacquot wrote: Bref, va te falloir apprendre la réalité des PME... Tu voudrais dire que les opérateurs ne comprennent pas leurs clients ? On savait déjà l'inverse, mais ça explique pas mal de choses d'un coup ;) -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
Bonsoir, Je n ai pas une grande habitude des PME. Mais d'apres ton explication un routeur de la marque Mikrotik est suffisant (il me semble). Cordialement Fabien On 3 nov. 2012, at 14:47, Jérôme Nicolle jer...@ceriz.fr wrote: Bonjour Fabien, On 03/11/2012 10:38, Fabien Delmotte wrote: Juste une petite question concernant le choix d'un constructeur. Comment faire pour choisir le matos quand les tables de routage en IPv4 sont enormes et que l'IPv6 pointe son nez. Il me semble que les cartes supportant cela en hardware sont relativement onereuseset que nous ne savons pas si les dites cartes tiendront 1,2,3 ans. Les petits routeurs d'entreprise, typiquement ce dont on parle là c'est du ISR-G2 ou 7200, à la rigueur ASR1001 chez Cisco, ou du SRX chez Juniper. Ces plate-formes (à l'exception de l'ASR) sont 100% soft, donc pas de souci avec le nombre de routes tant qu'il y a de la RAM. Pour en arriver à du routage matériel, tu es sur des besoins qui justifient des budgets qui ne justifient plus de se prendre la tête avec autant de détail ou de bidouillage : une paire de naimix 80 et c'est réglé. Ou bien, moins cher (du niveau d'un ASR) : CER2024 de chez Brocade. Peut être qu'une solution mixte est envisageable pour certaines societes afin de ne pas faire exploser les budgets. Là on va te répondre qu'une société n'a rien à foutre d'une full view. Une default + le 21 suffit et est déjà sur-dimensionnée dans la plupart des cas. La full view en RIB sert à fournir du transit ou à faire des stats drôles, la full view en FIB sert à optimiser ton routage au poil de fourmi près. Il y a donc deux approches : soit on monte des setups plus modestes quand on est pas assez fortunés pour jouer au grozopérateur, soit on rajoute des couches de bricolage qui feront hurler Raphaël et quelques autres puristes du chan qui ont probablement oublié leurs débuts. -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
On 03/11/2012 16:23, Fabien Delmotte wrote: d'apres ton explication un routeur de la marque Mikrotik est suffisant Dans pas mal de cas, oui, mais ils ont leur limites et elles sont parfois surprenantes. A l'heure actuelle, en contexte PME / petit hébergeur, je préfère encore du vyatta sur un serveur Dell ou équivalent que du mikrotik si c'est un setup que je ne serais pas seul à maintenir. -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
On 3 nov. 2012, at 13:10, Raphaël Jacquot sxp...@sxpert.org wrote: On 2 nov. 2012, at 23:01, Raphaël Maunier raphael.maun...@jaguar-network.com wrote: On 2 nov. 2012, at 19:46, Laurent CARON lca...@unix-scripts.info wrote: On Fri, Nov 02, 2012 at 05:36:39PM +0100, Raphaël Maunier wrote: Je conçois que dans le cas d'un opérateur il ne soit pas envisageable de gérer des routeurs soft (pour quelque raison que ça soit: fiabilité, gestion des révisions, hardware hétéroclyte, ...), mais dans le cas de $PME qui souhaite avoir une solution fiable et peu coûteuse, le jeu en vaut la chandelle. Je ne suis pas d'accord avec toi sur ce point. Si pour une PME ce point est critique, il y a toujours une solution autre que le Linux supporté par personne et qui en cas de soucis pourra avoir des conséquences plus désastreuses que les X k€ économisés au début de l'aventure. Donc, bien souvent le jeu n'en vaut pas la chandelle :) La PME en question n'a généralement pas les moyens de se payer un routeur dit hardware, donc, c'est pas vraiment le sujet Ah ? Jcrois que tu fais trop de bidouille depuis des années pour ne pas savoir combien coûte un routeur en HW. Un sw avec du bgp en route par défaut ( qui suffit à 90%) des mecs, ça coûte vraiment pas cher et même si c'est genre 2 fois plus cher que un serveur à 1000 euros, comment dire, si une PME sait pas investir 1000 euros de plus pour avoir un truc supporté, je dis que le pb n'est pas la ou on regarde hein :) Quand au linux supporté par personne c'est un non sens. Opérateur, opérateur, ne déforme pas mes propos ! Avoir la possibilité de payer un fournisseur de linux commercial pour pouvoir lui brailler dessus quand ca fonctionne pas, c'est une problématique de DSI de grosse boite, qui ne veux surtout pas savoir comment ça fonctionne. Voilà pourquoi tu n'es pas DSO, tu n'as toujours pas compris le vrai rôle d'un DSI .. Quand a la possibilité de faire des procès pour éventuellement récupérer des dommages et intérêts, c'est tout autant hors sujet quand on parle de vraie PME... Ça y est on t'a perdu dans les méandres de ton côté révolutionnaire ! Bref, va te falloir apprendre la réalité des PME... Heu, je crois que justement il faudrait que tu apprennes le risque à ne pas prendre comme dirait le Sbol. Une PME aura plus de mal à supporter une archi de bidouille qu'une archi constructeur ! Ne pas oublier une chose, les opérateurs alternatifs ( genre mon précédent employeur et mon actuel ) ont une masse de PME comme client qu'ils soient pure player ou une PME ou dans un secteur qui n'est pas full dépendant du net. Dans la plupart des cas, les mecs viennent vers nous pour justement parce que les mecs ont eu un mec qui avait installé le truc sous Linux il y a 2 ou 3 ans et il s'est barré. Donc , nous on arrive et même pas en rêve on reprend l'archi ! Par contre, on arrive et y a du HW , on sait reprendre et faire évoluer en douceur. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
On 3 nov. 2012, at 14:47, Jérôme Nicolle jer...@ceriz.fr wrote: Bonjour Fabien, On 03/11/2012 10:38, Fabien Delmotte wrote: Juste une petite question concernant le choix d'un constructeur. Comment faire pour choisir le matos quand les tables de routage en IPv4 sont enormes et que l'IPv6 pointe son nez. Il me semble que les cartes supportant cela en hardware sont relativement onereuseset que nous ne savons pas si les dites cartes tiendront 1,2,3 ans. Les petits routeurs d'entreprise, typiquement ce dont on parle là c'est du ISR-G2 ou 7200, à la rigueur ASR1001 chez Cisco, ou du SRX chez Juniper. Ces plate-formes (à l'exception de l'ASR) sont 100% soft, donc pas de souci avec le nombre de routes tant qu'il y a de la RAM. Pour en arriver à du routage matériel, tu es sur des besoins qui justifient des budgets qui ne justifient plus de se prendre la tête avec autant de détail ou de bidouillage : une paire de naimix 80 et c'est réglé. Ou bien, moins cher (du niveau d'un ASR) : CER2024 de chez Brocade. Peut être qu'une solution mixte est envisageable pour certaines societes afin de ne pas faire exploser les budgets. Là on va te répondre qu'une société n'a rien à foutre d'une full view. Une default + le 21 suffit et est déjà sur-dimensionnée dans la plupart des cas. La full view en RIB sert à fournir du transit ou à faire des stats drôles, la full view en FIB sert à optimiser ton routage au poil de fourmi près. Il y a donc deux approches : soit on monte des setups plus modestes quand on est pas assez fortunés pour jouer au grozopérateur, soit on rajoute des couches de bricolage qui feront hurler Raphaël et quelques autres puristes du chan qui ont probablement oublié leurs débuts. Je n'ai jamais , mais alors la jamais fais des routeurs en soft. Je préfère orienter les mecs sur du neuf / broke sur des switchs en route par défaut, que de faire de la bidouille. Même les gros ont commencé comme ça. Je me souviens quand Dailymotion est venu nous voir quand ils venaient de se lancer ( genre dans le premier mois ), on a installé un 3550 en bgp jusqu'à environ 1G puis un 3560G jusqu'à plus de 4G. Bon on faisait cuire un œuf dessus quand on a atteint 5,2G parce qu'on avait un lag 2g sur le panap avec 8k routes dans le bousin. Je suis sur qu'en route par défaut sans peering, on aurait pu faire plus :) même si je suis pro Juniper, le 3560G, est le cisco qui m'aura le plus impressionné pour le rapport prix/qualité/performance. Le cisco est d'ailleurs à mon avis encore en prod qq part chez Iguane :) Bref, ipv6 je ne sais pas, mais ipv4, pour moins de 2k tu peux faire up2 4G finger un the nez :) -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
On 03/11/2012 18:21, Raphaël Maunier wrote: Je n'ai jamais , mais alors la jamais fais des routeurs en soft. C'est surprenant que tu critiques le principe avec tant de conviction dans ce cas. -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
On 3 nov. 2012, at 20:14, Jérôme Nicolle jer...@ceriz.fr wrote: On 03/11/2012 18:21, Raphaël Maunier wrote: Je n'ai jamais , mais alors la jamais fais des routeurs en soft. C'est surprenant que tu critiques le principe avec tant de conviction dans ce cas. Je ne risque pas des infrastructures sur des trucs bidouillé , c'est tout. Le trucs pour jouer, c'est à la maison ou dans un lab pour faire mumuse, pas sur de la prod. Dans ma cave, j'ai du pfsense pour m'amuser, mais clairement dans un monde pro, je ne prendrais pas ça, ou à la rigueur pour de l'oob et encore, des petits SRX ou s'étonne soft ou encore Fortinet, j'ai plus confiance , et les même pas 10% de diff à provisionner, je les prends :) Même pour chez moi, j'hésite d'en prendre un. Encore une fois, si ton business en dépend, ne bidouille pas, si c'est du POC ou oui tu peux t'amuser. Je pars du principe que si ça ne scale pas avec un support pro et constructeur, et aussi en perf, je passe mon chemin. -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
On 03/11/2012 20:22, Raphaël Maunier wrote: Encore une fois, si ton business en dépend, ne bidouille pas, si c'est du POC ou oui tu peux t'amuser. Je pars du principe que si ça ne scale pas avec un support pro et constructeur, et aussi en perf, je passe mon chemin. Pour moi ça dépend de la confiance relative que tu apportes à des constructeurs plutôt qu'aux développeurs et intégrateurs de solutions logicielles. Pour ma part, étant donné l'opacité des constructeurs et leur mauvaise volonté à assurer un niveau de qualité et d'efficacité satisfaisant sur leurs gammes logicielles, l'open source est un choix pragmatique. Je prends pour exemple quelques cas concrets de bugs dont l'identification et la résolution a pris tellement de temps (en local, hors contrat de support, mais toujours moins cher que l'assurance appelée contrat de support) qu'il eut été plus rapide de patcher et/ou documenter une implémentation open source que de s'obstiner dans la voie du 100% proprio-cher-garanti. Je comprends parfaitement ton point de vue service provider : tes besoins ne permettent pas ces alternatives, que tu ne connais donc pas faute d'utilité. Pour certains de tes clients, tu pourrais être à la limite de rentabilité mais tes accords avec les constructeurs, ou ton habitude de bosser avec eux fait que le jeu n'en vaut pas la chandelle. Par contre en aucun cas tu ne peux critiquer la fiabilité de solutions open source. Le code est accessible, généralement assez simple dans les morceaux qui nous concernent, pour une compréhension de la logique de la solution, et assez documentée par des gens qui ont un état d'esprit plus propice aux échanges constructifs que les commerciaux de tes constructeurs. La différence que tu sembles ne pas saisir est qu'on est pas là uniquement dans une logique de service provider mais aussi dans une logique d'intégrateur. Qu'un de tes employeurs ne soit pas staffé pour se faire chier à intégrer du très spécifique et préfère composer avec des briques sur étagère, c'est une évidence. Mais il y a des gens dont le métier est de faire du sur mesure, et qui travaillent plus efficacement, par la faute même des constructeurs, avec de l'open source qu'avec du cisco/juniper/whatever. Les service provider et les intégrateurs sont complémentaires, c'est une évidence dès lors qu'on sort des sentiers battus. Et ta position tendant à ignorer cette évidence m'amène à me demander si ta stratégie est de t'adapter à ton client ou d'adapter ton client à ta logique. Un peu comme SAP dans le monde du progiciel, avec sa longue liste de cadavres d'entreprises mortes de la marche forcée vers le conformisme industriel. Il y a de la place pour tout le monde, tu ne peux pas dénigrer le travail des intégrateurs sans te couper d'un pan entier du marché et de la compétence. Pour ma part, je respecte les orfèvres de l'open source qui ont crée une vaste logithèque, très bien documentée, capable aujourd'hui de répondre à quasiment tous les besoins de nos clients, dont l'accès à Internet. Et quand bien même tu aurais raison quant à la fiabilité relative de certaines solutions eu égard au coût des assurances quasi obligatoire, vendues comme contrats de supports, tu peux admettre qu'on peut faire le choix de gérer le risque d'exploitation inhérent à toute technologie en interne, en créant de l'emploi pour ça, plutôt qu'en se rendant volontairement dépendant de son constructeur. C'est un business model différent, que tu n'est certainement pas en position de critiquer sur ce point. -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
Désolé de m'immiscer dans votre échange Pro/anti. Je me permet de donner mon point de vue sur un débat qui aura aussi peu de réponse qu'un autre troll mondiale dans le monde des smartphone. J'ai pendant longtemps déployé des solutions basées sur du BSD (Quagga, PF, racoon and co ….) et depuis 3-4 ans je déploie principalement du constructeur (Juniper, Cisco principalement). Je n'ai pas le sentiment d'avoir plus ou moins de support avec l'un ou l'autre. Je peux pas dire que les constructeurs soient plus réactifs à mes problèmes quotidien que ne l'est la communauté Opensource autour de BSD. Sachant, dans le cas de Juniper par exemple, que Junos doit pas mal à Freebsd. Je crois que la question et donc le choix finale ne se fait pas autour de ça mais plutôt autour de la fameuse question : Intégration verticale ou horizontale ? (D'où ma référence au troll mondiale ….) La première problématique que l'on a rencontré avec les solutions BSD est leur industrialisation et la capacité à le faire avec une croissance soutenue ainsi que la capacité à avoir une solution homogène et parfaitement intégrée à tous les niveaux. Avec ces solutions on récupère des briques à droite, à gauche en espérant que chacune respecte les RFC, les standards, appelez ça comme vous le voulez. Et là, malgré que ce soit de l'Opensource, vous pouvez avoir de franche surprise et de sacrée crises de nerf. Ajoutez à cela que chacune des briques n'évoluent pas toutes au même rythme et vous pouvez vous retrouver bloquer pendant pas mal de temps sur un problème parce que la brique d'à côté n'a pas évolué depuis une éternité. Donc oui les solutions Opensource fonctionnent très bien mais leur intégration avec le reste du monde peut parfois laisser à désirer. Leur industrialisation peut s'avérer être aussi un vrai casse tête. Mais ce que j'aime bien dans l'idée de ces solutions, c'est la nécessité de recruter des gens avec une tête bien faite et pas simplement des gens ayant passé une certification constructeur et ne jurant que par ce constructeur parce qu'ils sont incapable d'utiliser autre chose. Ce qui ne veut pas dire que dans les pro constructeurs, on ne trouve pas des gens avec des têtes bien faite. Il ne faut pas me faire dire ce que je n'ai pas dit. Mais avec l'Opensource c'est un pré requis indispensable. Le côté agréable des solutions constructeurs est justement leur intégration et leur industrialisation. Soit parce que le constructeur développe une gamme complète de solutions sur toutes les couches, soit parce qu'ils ont de bons partenariats permettant de faire évoluer toutes les briques au même rythme. En revanche, je les haie quand ils m'expliquent que je dois de nouveaux m'affranchir d'une license pour rajouter la moindre fonctionnalité basique !! Et ce phénomène est plus ou moins énorme en fonction du constructeur. Suivez mon regard …. Dans le monde Opensource, ce qui va vous limiter, ce sont vos compétences, pas une stratégie commerciale à se jeter dans la Seine …. Ne pas être lié à une histoire de license permet bien plus de réactivité et de créativité pour répondre à une nouvelle problématique. Créativité ne veut pas dire bidouille, on peut l'être tout en respectant les règles de l'art. Pour le côté bidouille, on peut tout aussi bien en faire avec une solution constructeur qu'avec une solution Opensource. On fait de la bidouille quand on ne maîtrise pas la techno. Et il suffit de regarder l'implémentation de solutions constructeurs dans certaines entreprises pour s'apercevoir que la bidouille est fortement présente ….. PME et entreprises du CAC 40 confondues …. Bref, ça ne fait qu'un éternel débat supplémentaire. Le 3 nov. 2012 à 20:42, Jérôme Nicolle jer...@ceriz.fr a écrit : On 03/11/2012 20:22, Raphaël Maunier wrote: Encore une fois, si ton business en dépend, ne bidouille pas, si c'est du POC ou oui tu peux t'amuser. Je pars du principe que si ça ne scale pas avec un support pro et constructeur, et aussi en perf, je passe mon chemin. Pour moi ça dépend de la confiance relative que tu apportes à des constructeurs plutôt qu'aux développeurs et intégrateurs de solutions logicielles. Pour ma part, étant donné l'opacité des constructeurs et leur mauvaise volonté à assurer un niveau de qualité et d'efficacité satisfaisant sur leurs gammes logicielles, l'open source est un choix pragmatique. Je prends pour exemple quelques cas concrets de bugs dont l'identification et la résolution a pris tellement de temps (en local, hors contrat de support, mais toujours moins cher que l'assurance appelée contrat de support) qu'il eut été plus rapide de patcher et/ou documenter une implémentation open source que de s'obstiner dans la voie du 100% proprio-cher-garanti. Je comprends parfaitement ton point de vue service provider : tes besoins ne permettent pas ces alternatives, que tu ne connais donc pas faute d'utilité. Pour certains de tes clients, tu pourrais être à la
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
On Sat, Nov 3, 2012, at 8:58, Raphaël Maunier wrote: Combien de mecs qui l'installent savent lire un code source ? X% des gens maîtrisent les fichiers de conf sans comprendre le protocole, Y% des gens seront incapable de débug en cas de soucis car ils n'auront pas la maîtrise des fondamentaux. Des fois, c'est le linux/UNIX qui déconne et pas le soft de routage et la... C'est le drame Tu n'a pas du travailler dans des boites de linuxiens. Je ne parle pas de boites qui utilisent Linux comme n'importe quelle autre produit. Je parle de boites ou c'est l'alpha et l'omega, Linux or die. Oui, ca existe, et je crois qu'on a des representants sur la liste. Je parle la de boites ou les gens qui ne savent pas lire un code source n'ont pas leur place. C'est un mode de fonctionnement totalement different de ce que tu dois pratiquer habituellement, mais ca existe bel et bien. Oui, mais je préfère encore travailler avec un matos ou y a des équipes dédiées qui bossent sur la résolution des bugs que d'attendre qu'un mec dans sa cave fixe le pb du code qu'il a pondu et qui est super populaire. Tu n'as jamais du attendre 2 ans pour la correction d'un bug que tu as du trouver apres seulement une mois de la mise en prod ? Ou attendre 3 mois juste pour confirmer qu'il y a bien un bug, et non pas un probleme de config de tton cote ? Ah, non; tu devais acheter chez ton constructeur des metres cubes a la fois, de quoi le garder en alerte permanente. Mauvaise nouvelle, quand tu achetes juste une ou 2 paires de boitiers, les choses changement violamment. C'est la que beaucoup de gens se posent plusieurs fois la question d'utiliser une boite noire avec support constructeur ou avoir une bricole a base d'open source. Et dans certains cas, la bricole open-source gagne haut-la main, pas seulement dans les boites des barbus (mentionnes plus haut). Ça dépend du matos, ça peut aller de qq centaines d'euros pour les tout petits routeurs à qq milliers d'euros pour les gros routeurs backbone. Pour avoir le mec qui sait comment ca marche dans les 45 minutes ? Pour les gros matos achetes en quantite probablement, mais pour les petits boitiers achetes a moins de 10, il faut generalement se batailler avec plusieurs niveaux de support juste pour confirmer qu'il y a bien un probleme. Et non, le coup de j'ai le telephone de Laurent G. (ou l'equivalent chez ton constructeur favori - s'il y en a un) ca ne marche pas a tous les coups et pour tout le monde. un bug Mpls sur cett version, pour le résoudre ... Désactivez Mpls ... et voila comment finir avec des solutions a base d'open source --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
On Sat, Nov 3, 2012, at 18:10, Raphaël Maunier wrote: Dans la plupart des cas, les mecs viennent vers nous pour justement parce que les mecs ont eu un mec qui avait installé le truc sous Linux il y a 2 ou 3 ans et il s'est barré. Oui, mais il y a 2 ou 3 ans, c'etait la solution qui leur avait permis d'avancer.. Et oui, si le mec aurait reste, ca aurait ete son boulot de passer sur quelque-chose de plus serieux (et eventuellement ne pas arriver chez vous). Been there, done that. Donc , nous on arrive et même pas en rêve on reprend l'archi ! T'inquiete, baisser son pantalon devant le client, il y en a qui le font, et il y aura toujours. Il y a (malhereusement) de la place pour tout le monde dans l'ecosysteme --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
On Sat, Nov 3, 2012, at 20:22, Raphaël Maunier wrote: Je ne risque pas des infrastructures sur des trucs bidouillé , c'est tout. Ce que tu appelles bidouille, il y a d'autres qui appellent du solide. OK, sur du 100% routage ca se discute, mais des qu'il y a d'autres fonctionalites (notamment LB ou firewall), ca tourne vite a la guerre ideologique. N'oublie pas non plus que le 3650G que tu mets sur une plate-forme de prod en DC, selon le constructeur c'est un desktop switch - access (l'espece qu'on met dans un reseau bureautique). La c'est toi qui passe dans le domaine de la bidouille, pour ne pas avoir suivi la bible. Pas oublier que sur certains produits (3560/3750) la double alimentation etait une salle bidouille seulement a moitie fonctionelle jusqu'a il y a pas si longtemps que ca (l'arivee des 3560X/3750X, il y a meme pas 2 ans). Alors que la double alim c'etait donne pour un serveur, a meme pas 1000 EUR. Les choses sont un peu differentes aujourd'hui (mais le 3560X reste un desktop switch selon Cisco), mais ca n'a pas toujours ete le cas, et les anciens reflexes se manifestent encore. Essaye d'asismiler le fait que le monde n'est pas (malhereusement) pas tout noir ou tout blanc. Il y a plein de nuances de gris au milieu qui nous font pourrir la vie parfois. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
On 3 nov. 2012, at 20:42, Jérôme Nicolle jer...@ceriz.fr wrote: On 03/11/2012 20:22, Raphaël Maunier wrote: Encore une fois, si ton business en dépend, ne bidouille pas, si c'est du POC ou oui tu peux t'amuser. Je pars du principe que si ça ne scale pas avec un support pro et constructeur, et aussi en perf, je passe mon chemin. Pour moi ça dépend de la confiance relative que tu apportes à des constructeurs plutôt qu'aux développeurs et intégrateurs de solutions logicielles. Pour ma part, étant donné l'opacité des constructeurs et leur mauvaise volonté à assurer un niveau de qualité et d'efficacité satisfaisant sur leurs gammes logicielles, l'open source est un choix pragmatique. Je prends pour exemple quelques cas concrets de bugs dont l'identification et la résolution a pris tellement de temps (en local, hors contrat de support, mais toujours moins cher que l'assurance appelée contrat de support) qu'il eut été plus rapide de patcher et/ou documenter une implémentation open source que de s'obstiner dans la voie du 100% proprio-cher-garanti. Je comprends parfaitement ton point de vue service provider : tes besoins ne permettent pas ces alternatives, que tu ne connais donc pas faute d'utilité. Pour certains de tes clients, tu pourrais être à la limite de rentabilité mais tes accords avec les constructeurs, ou ton habitude de bosser avec eux fait que le jeu n'en vaut pas la chandelle. Par contre en aucun cas tu ne peux critiquer la fiabilité de solutions open source. Bah, ce n'est pas ce que j'ai dis. Je parle de l'open source pour faire tourner ton BGP. Je n'ai pas de windows comme serveur dns, mail, www. Mon monitoring perso, c'est Observium et j'ai même filé qq euros au projet :) Le code est accessible, généralement assez simple dans les morceaux qui nous concernent, pour une compréhension de la logique de la solution, et assez documentée par des gens qui ont un état d'esprit plus propice aux échanges constructifs que les commerciaux de tes constructeurs. La différence que tu sembles ne pas saisir est qu'on est pas là uniquement dans une logique de service provider mais aussi dans une logique d'intégrateur. Si si je comprends parfaitement. Je conçois que des gens puissent utiliser de l'opensource pour faire tourner leurs serveurs web ou autre serveurs ... Qu'un de tes employeurs ne soit pas staffé pour se faire chier à intégrer du très spécifique et préfère composer avec des briques sur étagère, c'est une évidence. Heu ? Tu es au courant de ce que je faisais avant hein ? Si y a bien qq qui faisais la stratégie d'ingénierie avant, c'était moi hein :) Le choix a été fait de faire en sorte de se concentrer sur notre métier d'opérateur, et non pas d'integrateur de solutions sur notre propre backbone. Vu qu'on est passé de 0 meg à plus de 400G en moins de 4 ans, avec une des meilleures progression dans le classement Renesys, je crois que j'ai plutôt fais le bon choix. Mais il y a des gens dont le métier est de faire du sur mesure, et qui travaillent plus efficacement, par la faute même des constructeurs, avec de l'open source qu'avec du cisco/juniper/whatever. Encore une fois, tu as un gros pépins, avec des routeurs Opensource, tu es en galère. Avec une solution HW, tu trouveras très facilement qqn. À l'inverse, tu as un MSSQL, tu trouveras plein d'experts cliclodrome mais incompétents au possible. Et par contre sur du Mysql, des mecs qui maîtrisent et qui franchement sont des vrais tueurs, tu en trouveras à la pele. Dans ce cas la, y a pas photo l'opensource dépasse de très loin les solutions M$ et même OSX Les service provider et les intégrateurs sont complémentaires, c'est une évidence dès lors qu'on sort des sentiers battus. Et ta position tendant à ignorer cette évidence m'amène à me demander si ta stratégie est de t'adapter à ton client ou d'adapter ton client à ta logique. Faux ! Mes clients ou futurs clients viennent me/nous voir pour les aider à améliorer, optimiser leurs infrastructures. Un peu comme SAP dans le monde du progiciel, avec sa longue liste de cadavres d'entreprises mortes de la marche forcée vers le conformisme industriel. Encore une fois, dans les logiciels pour de l'IT, l'opensource ou le dev interne pour ton IT est souvent la meilleure solution. Bon ensuite, tu es une grosse boite, tu es super fan d'opensource, et tu fais tout avec. Tu décide un jour de prendre un expert comptable pour mettre ta compta au carré. Montres lui ton soft Opensource pour la compta ... On a bien rire. Ne me dit pas, ouais, mauvais expert comptable, changer expert comptable ... La ça passera juste pas hein :) Il y a de la place pour tout le monde, tu ne peux pas dénigrer le travail des intégrateurs sans te couper d'un pan entier du marché et de la compétence. Je ne dénigre pas, loin de la. Faire une archi BGP scalable sur des bsd/Linux , ça reste de la bidouille. Les opérateurs ne
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
Relis ce que j'ai dis ... J'ai dis que quitte à faire un truc cheap, je préfère faire avec un truc supporté. Bgp est supporté par Cisco, et du temps ou cisco me parlait encore ( avant qu'ils perdent l'AO en 2008), ils ont répondu aux questions BGP que j'avais sur le 3560. Et pour l'opensource, j'ai répondu dans un autre mail :) -- Raphaël Maunier Mob : +33 6.86.86.81.76 skype : rmaunier Sent from my iPad On 3 nov. 2012, at 22:21, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote: On Sat, Nov 3, 2012, at 20:22, Raphaël Maunier wrote: Je ne risque pas des infrastructures sur des trucs bidouillé , c'est tout. Ce que tu appelles bidouille, il y a d'autres qui appellent du solide. OK, sur du 100% routage ca se discute, mais des qu'il y a d'autres fonctionalites (notamment LB ou firewall), ca tourne vite a la guerre ideologique. N'oublie pas non plus que le 3650G que tu mets sur une plate-forme de prod en DC, selon le constructeur c'est un desktop switch - access (l'espece qu'on met dans un reseau bureautique). La c'est toi qui passe dans le domaine de la bidouille, pour ne pas avoir suivi la bible. Pas oublier que sur certains produits (3560/3750) la double alimentation etait une salle bidouille seulement a moitie fonctionelle jusqu'a il y a pas si longtemps que ca (l'arivee des 3560X/3750X, il y a meme pas 2 ans). Alors que la double alim c'etait donne pour un serveur, a meme pas 1000 EUR. Les choses sont un peu differentes aujourd'hui (mais le 3560X reste un desktop switch selon Cisco), mais ca n'a pas toujours ete le cas, et les anciens reflexes se manifestent encore. Essaye d'asismiler le fait que le monde n'est pas (malhereusement) pas tout noir ou tout blanc. Il y a plein de nuances de gris au milieu qui nous font pourrir la vie parfois. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
Le 3 nov. 2012 à 22:39, Raphaël Maunier raphael.maun...@jaguar-network.com a écrit : Je ne dénigre pas, loin de la. Faire une archi BGP scalable sur des bsd/Linux , ça reste de la bidouille. Les opérateurs ne supportent PAS leurs clients en cas de soucis ! CQFD Admettons que je prenne mon BSD que j'enlève l'inutile que je ne garde que ce dont ma solution BGP a besoin, que je le compile pour un hw spécifique et que je le fasse fabriquer à la chaine. Est ce que cela reste de la bidouille ? Je prends pas position hein, je cherche juste à comprendre l'histoire de la bidouille. Julien. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
On 3 nov. 2012, at 21:35, Julien Boussu d...@xgs-france.com wrote: Désolé de m'immiscer dans votre échange Pro/anti. Avec plaisir, pour une fois ça ne troll pas beaucoup, il y a eu des tentatives, mais bon ,c'est Frnog hein :) Je me permet de donner mon point de vue sur un débat qui aura aussi peu de réponse qu'un autre troll mondiale dans le monde des smartphone. J'ai pendant longtemps déployé des solutions basées sur du BSD (Quagga, PF, racoon and co ….) et depuis 3-4 ans je déploie principalement du constructeur (Juniper, Cisco principalement). Je n'ai pas le sentiment d'avoir plus ou moins de support avec l'un ou l'autre. Je peux pas dire que les constructeurs soient plus réactifs à mes problèmes quotidien que ne l'est la communauté Opensource autour de BSD. Sachant, dans le cas de Juniper par exemple, que Junos doit pas mal à Freebsd. Je crois que la question et donc le choix finale ne se fait pas autour de ça mais plutôt autour de la fameuse question : Intégration verticale ou horizontale ? (D'où ma référence au troll mondiale ….) La première problématique que l'on a rencontré avec les solutions BSD est leur industrialisation et la capacité à le faire avec une croissance soutenue ainsi que la capacité à avoir une solution homogène et parfaitement intégrée à tous les niveaux. Avec ces solutions on récupère des briques à droite, à gauche en espérant que chacune respecte les RFC, les standards, appelez ça comme vous le voulez. Et là, malgré que ce soit de l'Opensource, vous pouvez avoir de franche surprise et de sacrée crises de nerf. Ajoutez à cela que chacune des briques n'évoluent pas toutes au même rythme et vous pouvez vous retrouver bloquer pendant pas mal de temps sur un problème parce que la brique d'à côté n'a pas évolué depuis une éternité. Donc oui les solutions Opensource fonctionnent très bien mais leur intégration avec le reste du monde peut parfois laisser à désirer. Leur industrialisation peut s'avérer être aussi un vrai casse tête. Mais ce que j'aime bien dans l'idée de ces solutions, c'est la nécessité de recruter des gens avec une tête bien faite et pas simplement des gens ayant passé une certification constructeur et ne jurant que par ce constructeur parce qu'ils sont incapable d'utiliser autre chose. C'est pour cela que les certifications haut niveau que ce soit chez Juniper ou Cisco sont un peu plus sélectives que les certifs pourries de M$ Je parle bien sur des certifs un peu haut niveau, pas la junos de base ou le ccna/ccnp qui n'ont mais pas une once de valeur lorsque je recrute qqn ! Ce qui ne veut pas dire que dans les pro constructeurs, on ne trouve pas des gens avec des têtes bien faite. Oui, les certifs d'experts dénotent des mecs qui maîtrisent la partie protocole et partie soft/HW du constructeur. Il ne faut pas me faire dire ce que je n'ai pas dit. Mais avec l'Opensource c'est un pré requis indispensable. Le côté agréable des solutions constructeurs est justement leur intégration et leur industrialisation. Soit parce que le constructeur développe une gamme complète de solutions sur toutes les couches, soit parce qu'ils ont de bons partenariats permettant de faire évoluer toutes les briques au même rythme. En revanche, je les haie quand ils m'expliquent que je dois de nouveaux m'affranchir d'une license pour rajouter la moindre fonctionnalité basique !! Et ce phénomène est plus ou moins énorme en fonction du constructeur. Suivez mon regard …. Oui, j'aime bien Juniper, mais bon sur certains équipements, pour avoir de l'ipv6, il faut payer car des gens super bien pensant ( sûrement du marketing hein ) ont décidé de mettre l'ipv6 dans les licences de routage avancées... Ça fait juste 4 ans que je me bats avec eux. Dernier truc à la mode, tu veux avoir des stats ipv6, il faut une licence ipfix sur les MX, et C'est payant et pas genre 100 euros, mais plusieurs milliers de k€. Si l'ipv6 n'a pas encore bien avancé, c'est aussi en grande partie à cause des constructeurs. Dans le monde Opensource, ce qui va vous limiter, ce sont vos compétences, pas une stratégie commerciale à se jeter dans la Seine …. Ne pas être lié à une histoire de license permet bien plus de réactivité et de créativité pour répondre à une nouvelle problématique. Créativité ne veut pas dire bidouille, on peut l'être tout en respectant les règles de l'art. Pour le côté bidouille, on peut tout aussi bien en faire avec une solution constructeur qu'avec une solution Opensource. On fait de la bidouille quand on ne maîtrise pas la techno. Et il suffit de regarder l'implémentation de solutions constructeurs dans certaines entreprises pour s'apercevoir que la bidouille est fortement présente ….. PME et entreprises du CAC 40 confondues …. Bref, ça ne fait qu'un éternel débat supplémentaire. Le 3 nov. 2012 à 20:42, Jérôme Nicolle jer...@ceriz.fr a écrit : On 03/11/2012 20:22, Raphaël
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
Tout simplement, je suis ton opérateur de transit, la session flappe sans cesse, tu me fais un mail pour me dire : ouais pas bien pas beau ça casse. Tu as un Junisco, avec la version 52.xr42Xm, je te dis : ouais dans ta conf c'est ça où ça qui merde à cause du bidule truc chouette. Tu as un bsd avec un kernel ... Je te dis : J'ai pas testé, j'ai pas de test d'interop, je ne vais pas début, débrouille toi, ou reviens avec un routeur HW. Les opérateurs ne veulent pas gérer l'exception, il ne faut pas oublier que les mecs du niveau 1, n'ont pas encore le même niveau que les experts. Et, il ne faut pas se leurrer, ceux qui ont des routeurs UNIX, ne vont pas consommer du temps sur l'ingénierie pour faire valider le bug ou trouver la conf qui va bien pour l'interop... Voilà :) -- Raphaël Maunier Mob : +33 6.86.86.81.76 skype : rmaunier Sent from my iPad On 3 nov. 2012, at 22:50, Julien Boussu d...@xgs-france.com wrote: Le 3 nov. 2012 à 22:39, Raphaël Maunier raphael.maun...@jaguar-network.com a écrit : Je ne dénigre pas, loin de la. Faire une archi BGP scalable sur des bsd/Linux , ça reste de la bidouille. Les opérateurs ne supportent PAS leurs clients en cas de soucis ! CQFD Admettons que je prenne mon BSD que j'enlève l'inutile que je ne garde que ce dont ma solution BGP a besoin, que je le compile pour un hw spécifique et que je le fasse fabriquer à la chaine. Est ce que cela reste de la bidouille ? Je prends pas position hein, je cherche juste à comprendre l'histoire de la bidouille. Julien. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
Mais sauf erreur de ma part, il n'est pas acquis que le problème vienne du routeur du client. Le problème peut certainement venir de chez toi. Soit parce que ton routeur BGP a un vrai problème soit parce qu'il est possible qu'il ne respecte pas certains standards ! Mais si le problème vient de chez ton client, dans les deux cas (Solution Unix ou constructeur), il a un problème de compétence ou de feignantise (C'est souvent le cas). Rassure moi d'une chose, si ton client avec sa solution UNIX arrive avec une analyse bien couillue et qu'il démontre que le flat n'est pas de son fait, tu prends quand même en compte sa remarque et fais un minimum d'analyse chez toi ou tu attends qu'un client avec une solution constructeur vienne à son tour te le signaler ? Quoi qu'il en soit, je ne pense pas que l'argument L'opérateur ne supporte pas est une raison pour penser que la solution UNIX est une bidouille. Combien de client avec une belle solution contructeur valant plus milliers de K€ m'ont appelé pour signaler un dysfonctionnement alors qu'ils sont tout simplement pas foutu de maîtriser leur solution ! Où est la bidouille dans ce cas …. Malgré tout je suis pleinement satisfait de mes séries M et de mes SRX ;-) Julien. Le 3 nov. 2012 à 23:09, Raphaël Maunier raphael.maun...@jaguar-network.com a écrit : Tout simplement, je suis ton opérateur de transit, la session flappe sans cesse, tu me fais un mail pour me dire : ouais pas bien pas beau ça casse. Tu as un Junisco, avec la version 52.xr42Xm, je te dis : ouais dans ta conf c'est ça où ça qui merde à cause du bidule truc chouette. Tu as un bsd avec un kernel ... Je te dis : J'ai pas testé, j'ai pas de test d'interop, je ne vais pas début, débrouille toi, ou reviens avec un routeur HW. Les opérateurs ne veulent pas gérer l'exception, il ne faut pas oublier que les mecs du niveau 1, n'ont pas encore le même niveau que les experts. Et, il ne faut pas se leurrer, ceux qui ont des routeurs UNIX, ne vont pas consommer du temps sur l'ingénierie pour faire valider le bug ou trouver la conf qui va bien pour l'interop... Voilà :) -- Raphaël Maunier Mob : +33 6.86.86.81.76 skype : rmaunier Sent from my iPad On 3 nov. 2012, at 22:50, Julien Boussu d...@xgs-france.com wrote: Le 3 nov. 2012 à 22:39, Raphaël Maunier raphael.maun...@jaguar-network.com a écrit : Je ne dénigre pas, loin de la. Faire une archi BGP scalable sur des bsd/Linux , ça reste de la bidouille. Les opérateurs ne supportent PAS leurs clients en cas de soucis ! CQFD Admettons que je prenne mon BSD que j'enlève l'inutile que je ne garde que ce dont ma solution BGP a besoin, que je le compile pour un hw spécifique et que je le fasse fabriquer à la chaine. Est ce que cela reste de la bidouille ? Je prends pas position hein, je cherche juste à comprendre l'histoire de la bidouille. Julien. --- 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] Routeurs BGP : Conseil de topologie
On 3 nov. 2012, at 23:22, Julien Boussu d...@xgs-france.com wrote: Mais sauf erreur de ma part, il n'est pas acquis que le problème vienne du routeur du client. Le problème peut certainement venir de chez toi. Soit parce que ton routeur BGP a un vrai problème soit parce qu'il est possible qu'il ne respecte pas certains standards ! Oui, et c'est déjà arrivé, et très récemment :) Mais si le problème vient de chez ton client, dans les deux cas (Solution Unix ou constructeur), il a un problème de compétence ou de feignantise (C'est souvent le cas). Rassure moi d'une chose, si ton client avec sa solution UNIX arrive avec une analyse bien couillue et qu'il démontre que le flat n'est pas de son fait, tu prends quand même en compte sa remarque et fais un minimum d'analyse chez toi ou tu attends qu'un client avec une solution constructeur vienne à son tour te le signaler ? Oui, c'est arrivé, parce que le mec il avait toutes les traces et que Il maîtrisait la partie Juniper ! Et le soucis était ... Sur le lien de transport. Et quand tu reçois un mail sur ce genre d'incident c'est plutôt : marche pas, j'ai un corei7 avec 256G de Ram et la dernière beta de Bird, donc, c'est pas moi, c'est votre routeur ! Donc bon, tu comprendras qu'on ne prenne pas vraiment au sérieux ce genre de mails. Sur 1 cas sur 100 tu as un mec qui en face est vraiment extrêmement compétent, et son mail est structuré, y a toutes les traces, les infos et un truc du genre : après avoir tout testé, je suspecte un soucis de communication bla bla bla, pourrions-nous faire un call pour en parler. La les mecs de l'ingénierie, ne se posent pas de questions et contactent le mec directement. Quoi qu'il en soit, je ne pense pas que l'argument L'opérateur ne supporte pas est une raison pour penser que la solution UNIX est une bidouille. En routeur BGP, pour moi, c'est de la bidouille en tout cas. Combien de client avec une belle solution contructeur valant plus milliers de K€ m'ont appelé pour signaler un dysfonctionnement alors qu'ils sont tout simplement pas foutu de maîtriser leur solution ! Voilà pourquoi nous avons un job, et mon avis sur la question est que nos clients doivent se concentrer sur leur cœur de métier . Le routage, pour un pure player qui doit maîtriser son appli, c'est pas son métier, qu'il nous laisse le faire ( opérateur ou intégrateur ) . Où est la bidouille dans ce cas …. Oui, mais en 2 TPS 3 mouvements, bam, ça tombe en marche et tu peux maintenir. Une solution UNIX, imo, ça va prendre plus de temps et souvent devoir tout refaire. Malgré tout je suis pleinement satisfait de mes séries M et de mes SRX ;-) MX FTW Julien. Raphaël Le 3 nov. 2012 à 23:09, Raphaël Maunier raphael.maun...@jaguar-network.com a écrit : Tout simplement, je suis ton opérateur de transit, la session flappe sans cesse, tu me fais un mail pour me dire : ouais pas bien pas beau ça casse. Tu as un Junisco, avec la version 52.xr42Xm, je te dis : ouais dans ta conf c'est ça où ça qui merde à cause du bidule truc chouette. Tu as un bsd avec un kernel ... Je te dis : J'ai pas testé, j'ai pas de test d'interop, je ne vais pas début, débrouille toi, ou reviens avec un routeur HW. Les opérateurs ne veulent pas gérer l'exception, il ne faut pas oublier que les mecs du niveau 1, n'ont pas encore le même niveau que les experts. Et, il ne faut pas se leurrer, ceux qui ont des routeurs UNIX, ne vont pas consommer du temps sur l'ingénierie pour faire valider le bug ou trouver la conf qui va bien pour l'interop... Voilà :) -- Raphaël Maunier Mob : +33 6.86.86.81.76 skype : rmaunier Sent from my iPad On 3 nov. 2012, at 22:50, Julien Boussu d...@xgs-france.com wrote: Le 3 nov. 2012 à 22:39, Raphaël Maunier raphael.maun...@jaguar-network.com a écrit : Je ne dénigre pas, loin de la. Faire une archi BGP scalable sur des bsd/Linux , ça reste de la bidouille. Les opérateurs ne supportent PAS leurs clients en cas de soucis ! CQFD Admettons que je prenne mon BSD que j'enlève l'inutile que je ne garde que ce dont ma solution BGP a besoin, que je le compile pour un hw spécifique et que je le fasse fabriquer à la chaine. Est ce que cela reste de la bidouille ? Je prends pas position hein, je cherche juste à comprendre l'histoire de la bidouille. Julien. --- 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] [MISC] Routeurs BGP : Conseil de topologie
Bonsoir, Le 03/11/12, Raphaël Maunierraphael.maun...@jaguar-network.com a écrit : Tout simplement, je suis ton opérateur de transit, la session flappe sans cesse, tu me fais un mail pour me dire : ouais pas bien pas beau ça casse. Tu as un Junisco, avec la version 52.xr42Xm, je te dis : ouais dans ta conf c'est ça où ça qui merde à cause du bidule truc chouette. Tu as un bsd avec un kernel ... Je te dis : J'ai pas testé, j'ai pas de test d'interop, je ne vais pas début, débrouille toi, ou reviens avec un routeur HW. Mais, mais alors, à quoi servent les RFC, les standards, les normes et compagnie ? Dans le premier cas tu vas faire plus que ton boulot (puisque tu dépannes la config du client alors que c'est chez lui que ça merde, et qu'il est déjà censé payer des gens chez lui pour gérer ça), dans le deuxième cas il est possible que son BSD-Linux soit configuré comme il faut et que ça merde chez toi, donc tu refuses de dépanner le service pour lequel il paie. Naïvement (j'insiste sur le naïvement) je trouve ça assez aberrant comme situation. Ça me rappelle l'attitude des ISP grand public, qui vont expliquer au luser sous Windows XP comment configurer son parefeu (wait, wait, c'est le boulot d'un ISP ça ?) et faire chier celui qui signale une vraie panne mais n'utilise pas Windows (conclusion, son ADSL est en panne, mais il doit ruser avec la hotline pour obtenir la réparation à laquelle il a droit). C'est utopique de rêver de limites claires et rationnelles entre ce qui relève de la responsabilité du client, et ce qui relève de la responsabilité du fournisseur, avec entre les deux les Normes et le Contrat comme repères ? Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
On 3 nov. 2012, at 23:51, Julien Boussu julien.bou...@xgs-france.com wrote: Et quand tu reçois un mail sur ce genre d'incident c'est plutôt : marche pas, j'ai un corei7 avec 256G de Ram et la dernière beta de Bird, donc, c'est pas moi, c'est votre routeur ! Donc bon, tu comprendras qu'on ne prenne pas vraiment au sérieux ce genre de mails. Et si tu reçois un mail te disant j'ai un MX 5 avec la dernière release recommandée par Juniper donc le problème est chez vous ? On vérifie le niveau optique et on lui demande s'il a pas un optique chinois tombé du camion dans son Mx5. Car du bgp, entre MX/7600/ASR, ça frappe pas comme ça pour rien Tu le prends au sérieux ? Ou Sur 1 cas sur 100 tu as un mec qui en face est vraiment extrêmement compétent, et son mail est structuré, y a toutes les traces, les infos et un truc du genre : après avoir tout testé, je suspecte un soucis de communication bla bla bla, pourrions-nous faire un call pour en parler. La les mecs de l'ingénierie, ne se posent pas de questions et contactent le mec directement. Je suis rassuré :-) En routeur BGP, pour moi, c'est de la bidouille en tout cas. Soit. Oui, mais en 2 TPS 3 mouvements, bam, ça tombe en marche et tu peux maintenir. Une solution UNIX, imo, ça va prendre plus de temps et souvent devoir tout refaire. De ton point de vue. Imagine le mec qui se retrouve à devoir traiter une conf bien tordu à base de Cisco, qu'il ne pratique pas au quotidien, dont la logique peut parfois être une insulte à l'être Humain avec une cli qui laisse perplexe. Es tu toujours aussi convaincu de ton 2 TPS 3 mouvements ? J'ai eu le cas récemment. Cisco 7600, une conf avec 40 000 route-map et communautés , routeur chargé à bloc. Première étape, faire découvrir au mec les peer-group et la simplification de sa conf sur les communautés. Donc, objectif l'aide, on gagne en cpu, et on peut lire la conf enfin, et tout rentre dans l'ordre. 2 semaines après, il rajoute plein de truc, et bam re-100% de cpu. Après débug et conseil, on trouve ( pas moi cette fois ci) , que une acl ipv6 puntait tout vers le cpu, on modifie l'acl, tout rentre dans l'ordre. Pourquoi on a pris du temps à trouver ( plus d'une semaine sur l'acl ipv6 ) ? Parce que il n'avait pas son HW sous maintenance et qu'on a du faire tourner la conf pour trouver. J'en parle ensuite à un mec qui parle cisco comme première langue , en 30 sec il me dit : le mec aurait pas rajouteé une acl ipv6 par hasard ? J'en reviens à l'intégration. Je partage tout à fait ton point de vue sur le fait qu'en tant qu'opérateur tu ne puisses pas gérer tous les cas d'architecture et conseil ton client de s'orienter vers des solutions que tu pourras gérer. Ca me paraît sain. Tu sais que ça fonctionnera et tu pourras lui garantir son SLA. Maintenant, si j'ai en face de moi un mec qui maîtrise de A à Z sa solution que je ne lui ai pas conseillé après tout ça le regarde. Bien sur que oui :) mais s'il a une merde, je ne pourrais pas l'aider, that's IT Le nerf de la guerre étant la compétence de celui qui la gère et l'argent et c'est là où se trouve le point de départ de la bidouille. Julien. Malgré tout je suis pleinement satisfait de mes séries M et de mes SRX ;-) MX FTW Julien. Raphaël Le 3 nov. 2012 à 23:09, Raphaël Maunier raphael.maun...@jaguar-network.com a écrit : Tout simplement, je suis ton opérateur de transit, la session flappe sans cesse, tu me fais un mail pour me dire : ouais pas bien pas beau ça casse. Tu as un Junisco, avec la version 52.xr42Xm, je te dis : ouais dans ta conf c'est ça où ça qui merde à cause du bidule truc chouette. Tu as un bsd avec un kernel ... Je te dis : J'ai pas testé, j'ai pas de test d'interop, je ne vais pas début, débrouille toi, ou reviens avec un routeur HW. Les opérateurs ne veulent pas gérer l'exception, il ne faut pas oublier que les mecs du niveau 1, n'ont pas encore le même niveau que les experts. Et, il ne faut pas se leurrer, ceux qui ont des routeurs UNIX, ne vont pas consommer du temps sur l'ingénierie pour faire valider le bug ou trouver la conf qui va bien pour l'interop... Voilà :) -- Raphaël Maunier Mob : +33 6.86.86.81.76 skype : rmaunier Sent from my iPad On 3 nov. 2012, at 22:50, Julien Boussu d...@xgs-france.com wrote: Le 3 nov. 2012 à 22:39, Raphaël Maunier raphael.maun...@jaguar-network.com a écrit : Je ne dénigre pas, loin de la. Faire une archi BGP scalable sur des bsd/Linux , ça reste de la bidouille. Les opérateurs ne supportent PAS leurs clients en cas de soucis ! CQFD Admettons que je prenne mon BSD que j'enlève l'inutile que je ne garde que ce dont ma solution BGP a besoin, que je le compile pour un hw spécifique et que je le fasse fabriquer à la chaine. Est ce que cela reste de la bidouille ? Je prends pas position hein, je cherche juste à comprendre
