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: >> Aussi, les opérateurs de transit, lorsqu'ils verront en cas de soucis qu'il >> s'agit de routeurs sur Linux, et bien ils cesseront le débug et te diront >> d'aller t'acheter un routeur ... à tord ou à raison, ce n'est pas la >> question, c'est jusqu'à quel point tu fais confiance dans la solution ( >> support, acceptation des équipes interne et externe ... ) > > Bonsoir, > > Il est vrai qu'un routeur soft (Linux, *BSD, ...) ne te permet pas de > bénéficier du support d'un constructeur, mais il faut s'éloigner du trop > célèbre "nobody ever got fired for buying $SHIT equipment". > > Avoir du support chez Cisco, Juniper pour un routeur, IBM, HP, Dell pour > un serveur c'est bien, mais ça ne fait pas tout. > > 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 :) > > 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. 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 imposssssiibllle 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. 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 ... > > 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 > > Quel constructeur/éditeur/... n'a jamais connu de bug majeur sur un de > ses équipements ? Juniper ? Cisco ? Brocade ? Dell ? ... ? > > 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 :) > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
