Bonjour la ML,
+1000 sur ce que dit Guillaume.
Quelqu'un qui n'a pas les notions des protocoles et des concepts qui les
entourent ne restera qu'un technicien, pas un ingénieur, qui aura lui, grâce à
ces connaissances théoriques la capacité d'abstraction nécessaire pour dire par
exemple "Bah tiens là on peux utiliser de la CoS avec du 802.1Q, le switch va
peut-être faire lui aussi faire du rewritting, etc".
Le technicien se contentera d'appliquer les consignes qu'on lui donne avec les
guidelines des ingés.
Merci pour les infos concernant la Juniper Academy Program.
Nous allons essayer de voir si c'est possible de diversifier nos cours, c'est
toujours bien de voir autre chose que du Cisco ;)
Julien
Le 13 août 2012 à 17:40, Fabien V. <list-fr...@beufa.net> a écrit :
> _Perso je préfère recruter un ingé qui comprend les protocoles, qu'un
> ingé qui sait taper les commandes, mais qui ne comprend pas pourquoi il
> les tape..._
>
> +1, je vois des signatures d'architectes réseaux (ingénieurs ou pas, peu
> importe) qui savent configurer (parfois après 2h de réflexion) un VLAN, mais
> qui ne comprenne toujours pas le protocole 802.1Q et la différence entre des
> ports tagged / untagged.
>
> Et franchement, je vois pas ce que le terme ingénieur vient faire dans ce
> bloubi boulga ! Je trouve que Renault c'est de la grosse chiotte, et pourtant
> je roule en Clio parce que j'ai pas les moyens d'acheter une Audi ^^ Chacun
> sa vision des choses et on fait ce qu'on peut avec ce qu'on a, l'herbe est de
> toute façon toujours plus verte ailleurs quand on s'engage un minimum sur des
> technos et qu'on ne fait pas des pirouettes tous les 3 mois.
>
> Pour moi, l'idée de montrer des optiques peut avoir du sens, Cisco ou autre,
> le principal de toute façon est qu'un ingé puisse sortir avec la connaissance
> globale sur des optiques 'standards'. Par expérience, je suis arrivé chez un
> intégrateur (en sortant de mon école de merde d'ingénieur xD), je connaissais
> peanuts de la différence entre du LX / SX / Whatever, ni même sur les très
> importants considérations de monomode / multimode (et même plus avec les 50
> ou 62,5/125) ... Alors quelque soit le constructeur ou la techno, ca peut
> permettre d'éviter de former des marketeux rompus à telle ou telle marque,
> c'est plus que positif !
>
> Bref, encore des critiques qui ne font pas avancer le schmilblick ;)
>
> ---
> Fabien VINCENT
> -------------------------------
> Twitter : beufanet
>
> Le 2012-08-13 17:22, Guillaume Barrot a écrit :
>
>> Bonjour la ML
>>
>> Je passerai outre l'évolution de ce thread, symptomatique de la ML en ce
>> moment ("Eh les gens, j'ai du matos gratuit" ==> "Cisco c'est de la
>> merde"), pour revenir sur un point : est-ce que se former sur Cisco c'est
>> pertinent ?
>>
>> Je ne pense pas que l'on puisse taper sur une école d'ingé sous
>> prétexte
>> qu'elle forme ses élèves sur Cisco et pas sur un autre constructeur. A
>> cela
>> deux raisons : 1) Cisco est un acteur majeur du réseau qu'on le veuille
>> ou
>> non 2) un diplome n'a jamais été un gage de compétences techniques
>> pointue,
>> directement opérationnelle en prod.
>>
>> Que les choses soient claires, je suis persuadé qu'il faille former des
>> ingénieurs sur autre chose que Cisco, et à tout choisir, je pense qu'un
>> formation correcte s'appuierait sur des outils open source (typiquement,
>> on
>> peut monter du lab sur Quagga ou autre), et ce de manière à
>> éventuellement
>> pouvoir creuser le code en cours de C en parallèle.
>>
>> Certains de vous ont parlé de GNS3, et bien sur le site du projet, dans
>> la
>> partie appliance, il y a possibilité de télécharger des routeurs
>> softs,
>> ainsi que des switchs soft. Ca ne sera clairement pas au niveau d'un
>> Nexus
>> ou d'un Tserie, mais si on part par là, toutes les écoles devraient
>> avoir
>> la possibilité de maniper sur du CRS1 en multi-chassis, ou du T-Matrix,
>> car
>> on ne sait jamais un ingénieur pourrait avoir à en faire un jour.
>> Clairement, le role de la formation est de donner les bases les plus
>> solides pour qu'on puisse ensuite, dans le cadre de ses expériences, se
>> former au jour le jour, et en fonction de l'arrivée des technos.
>>
>> Dire que se former sur Juniper c'est mieux que Cisco, c'est puéril. Je
>> me
>> rappelle d'un meeting avec des gens de Juniper qui nous parlaient de la
>> possibilité de router de l'IPv4 dans OSPFv3 sur MX et T séries, à
>> partir de Junos
>>
> 9.2<http://www.juniper.net/techpubs/software/junos/junos95/swconfig-routing/ospf3-multiple-address-families.html>
>> .
>> Alors y a bien une discussion a l'IETF sur ça, mais pour l'instant ça
>> ne
>> reste qu'un "proposed standard <http://tools.ietf.org/html/rfc5838>", et
>> ce
>> depuis avril 2010. Bon en plus, le meeting dont je vous parle avait lieu
>> avant Avril 2010, l'interop avec les autres constructeurs est donc
>> clairement assuré dans un cas comme ça...
>>
>> Pour autant, c'est normal avec du matériel constructeur d'avoir des
>> implémentations différentes, ainsi que des protocoles propriétaires,
>> et une
>> certaine opacité sur le code. C'est pour ça qu'on leur paye du support
>> d'ailleurs.
>> Faut-il se former sur ces technos pour autant ? Bien sur, c'est ce genre
>> de
>> matériel qu'on va trouver en prod. Faut-il ne connaitre qu'un seul
>> constructeur ? Non, c'est certain, c'est pas idéal, mais c'est pas plus
>> grave que ça, c'est surtout à ça que servent les premiers mois
>> (années) de
>> boulot.
>>
>> Posez vous une question toute bête : vous donneriez un réseau
>> opérateur à
>> gérer à un jeune fraîchement diplômé en faisant une entière
>> confiance à
>> son diplôme ? Il lui manquera toujours l'expérience, qui ne peut
>> s'acquérir
>> qu'en galérant à 2h du matin avec des collègues et en maudissant un
>> constructeur.
>>
>> Perso je préfère recruter un ingé qui comprend les protocoles, qu'un
>> ingé
>> qui sait taper les commandes, mais qui ne comprend pas pourquoi il les
>> tape...
>>
>> Pour en revenir à la formation en école, un GNS3 me parait être
>> l'outil
>> principal :
>> - possibilité d'émuler des Cisco
>> - possibilité d'émuler des Juniper
>> - possibilité d'émuler du Quagga + OpenVswitch
>> - possibilité de créer des VMs QEMU ou VirtualBox
>> Si les constructeurs veulent être représentés, ils n'ont plus qu'à
>> compiler
>> une version "training" de leur OS préféré en intégrant les drivers
>> d'Intel
>> E1000. Dans le cadre de formation, je pense que le fonctionnement du
>> controlplane est primordial, et qu'on ne va pas faire des tests de perfs
>> ...
>>
>> Dans les écoles où j'enseigne, on donne des cours de réseau (ESIEE /
>> IUT
>>
>>> de Vélizy) avec des professeurs qui font leurs supports de cours, qui
>>> ne se contentent pas de copier-coller les slides et supports Cisco
>>> Academy (il me semblait que c'était le travail premier d'un professeur
>>> de concevoir du matériel pédagogique).
>>
>> Voilà une réflexion bien plus pertinente : le role de l'enseignant est
>> bien
>> d'avoir un regard critique sur ce qu'il enseigne, et donc montrer les
>> différences d'interprétation de tel ou tel constructeur sur les normes
>> me
>> parait être bien plus pertinent comme contenu de cours, qu'un pompage
>> éhonté de slides marketing !
>>
>> ---------------------------
>> 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/
