Faut’il encore passer la CCNA (200-301) en 2020 ? mon expérience et l’automatisation

C’est un article pour faire un petit point de ce qu’est devenu la CCNA en 2020

En effet, la certification cisco CCNA existe depuis bien longtemps maintenant, plus précisément elle a été crée en 1998, année de la victoire des bleus

Déjà, quand j’étais en école d’ingénieur, et ca fait un bout de temps, on en parlait, vu que c’était déjà pas mal connu, dans le sens que Cisco faisait en sorte, que quand tu tapais un protocole sur google, comme par exemple OSPF, tu tombais dessus.

En école, on avait pas vraiment de switch Cisco, mais tu tombais très souvent sur de la doc cisco quand tu avais un parcours ingénierie réseaux

Bref, c’était déjà un moyen d’hameçonner les gens avant même qu’ils touchent à leur produits…

Quand j’ai commencé à travailler, ou plutôt juste avant en 2007, en septembre à la rentrée j’ai passé la CCNA

J’ai ensuite cherché un emploi, j’ai été pris, mais il faut remettre les choses dans leur contexte.

En tant qu’ingénieur réseaux, tu pars avec un avantage, dans le sens qu’inconsciemment, les recruteurs te font « confiance » pour ta capacité à apprendre rapidement.

Par exemple, cela peut paraître étonnant, mais en école d’ingé, je n’ai jamais touché à un switch Cisco.

Donc, quand tu fais l’entretien, ils voient ta personnalité, est ce que t’as l’air sérieux, est ce que tu vas pouvoir t’adapter dans leur équipes.

Le gars qui va t’embaucher, faut avoir cela en tête, a des problèmes, il a peut être pas assez de personnes dans son équipe, la documentation n’est pas rédigé correctement, les projets sont en retard etc, donc lui, quand il te voit, il va se dire, qu’est ce qu’il va m’apporter.

Est ce qu’il pourra faire ce que je lui demande ? « On doit faire un déploiement de 100 switch », est ce qu’il pourra gérer sans faire de boulette, est ce qu’il pourra remplacer X quand celui ci part en vacances

Bref, il veut quelqu’un qui se bouge, mais qui maîtrise aussi ce qu’il fait

Donc, quand il va prendre un junior, c’est assez difficile de juger, car vu qu’il a jamais travaillé, il n’a pas d’expérience, donc lui poser des questions sur des équipements qu’il a jamais touché ne permettra pas de jauger de la valeur du candidat

Par contre, si le candidat, de lui-même, a décidé de passer la CCNA, cela montre 2 choses:

• Il est motivé, et il a fait l’effort de passer un examen qui, au final, peu de gens le passe
• On peut lui poser des questions de « bases »

Du coup, la ou le recruteur n’avait aucune méthode pour juger un candidat, avec le CCNA, il peut lui poser des questions maintenant

Cela fait partie du jeu, si tu as le CCNA, tu doit être capable de répondre à des questions « basique »

Donc, à ce moment la, tu peux lui demander comment la table MAC se construit sur un switch, comment marche le routage, la différence entre TCP et UDP, ARP, ICMP

Bref, des questions basique mais si tu y répond bien, tu gagne beaucoup de points, car tu montre à ton recruteur que tu as le minimum syndicale pour facilement appréhender les problématique technique

En plus de cela, si tu as bien préparé le CCNA, tu apprend beaucoup de choses, à la fois théorique (protocoles etc) mais aussi sur les produits Cisco

Comment se connecter à un switch, configurer ospf etc bref, des choses pratique utile à une entreprise, car mine de rien, la plupart du temps, les entreprises utilisent des équipements Cisco

Donc au final ça te sera utile mais cet article aurait pu être rédigé il y a 10 ans, qu’est ce qu’il y a de vraiment nouveau en 2020 avec la certification 200-301

L’automatisation réseaux, la nouvelle révolution réseaux

Alors, une grosse nouveauté, et non des moindres, c’est l’introduction par Cisco de ce qui s’appelle l’automatisation réseaux

Perso, j’ai commencé à toucher au Cisco, depuis 2006, soit 14 ans ( déjà)

Et au final, si je reprend mes livres (todd lammle) qui m’ont permis de passer la certif, si je prend les switch et les routeurs, il n’y a pas tellement de différences.

Tu te rend compte que le domaine réseaux a vraiment peu évolué depuis 20 ans, c’est toujours la même chose en fait

Tu te connecte sur le switch, par telnet, SSH ou en console

Et tu tape les, à peu prés, même commande qu’il y a 20 ans sans exagération aucune

Il y a quelques différences par exemple sur les gammes Nexus, mais au final cela ressemble beaucoup…un ingé réseaux qui par exemple serait partis en 2000 en polynésie pour ouvrir un club de vacances, s’il revient aujourdhui, il lui faudrait quelques mois pour se remettre dans le bain…

Par contre, avec un développeur qui se met en pause pendant 20 ans, de l’eau aura coulé sous le pont, il y a tellement de nouveauté dans les framework, les langages etc

Du coup, je ne sas pas comment c’est partis, mais tout les « constructeur réseaux » se sont mis à l’automatisation

Mais déjà c’est quoi l’automatisation

C’est un besoin, par exemple, tu doit mettre à jour 100 switch en même temps, ajouter une route statique par exemple

A l’ancienne (c’est à dire jusque très récemment ou même maintenant ), tu te connecte sur chacun des 100 switch et tu tape la commande.

Si tu fais un petit calcul, le temps de te connecter, de taper la commande, de vérifier ce que tu as tapé, de te déconnecter, et de reconnecter sur un autre switch sans faire d’erreur c’est à dire en prenant son temps, on compte 3 min par switch

Donc pour mettre à jour tes switch avec quelque chose de très simple, il te faut 300 min,  soit 5 H, environ une journée de taff

Par contre, si tu automatise tout cela avec un script Python ou Ansible, tu lui de se connecter (peut être même en parallèle) à chacun des switch, de taper la commande, de vérifier et de faire un compte rendu à la fin.

Tu auras gagner en fiabilité, et tu auras gagner une journée de travail.

C’est vraiment quelque chose de nouveaux, par contre les équipements ne sont pas encore tous prêts.

Dans le sens, que jusqu’à récemment, la plupart des équipements réseaux fournissait une « interface » telnet ou SSH voire HTTPS, pour se connecter

Mais ces interfaces sont surtout des interfaces Homme-Machine, tu est connecté en SSH, et tu tape tes commandes, tu vois le résultat et tu avise.

Hors, de machine à machine, cela devient plus compliqué

Imagine un serveur qui se connecte à un autre serveur en SSH, et il « envoie » une commande, tu as des temps de latence par exemple combien de temps va mettre la réponse à venir, quel type de réponse il va y avoir, de plus ce n’est pas structuré, il faut parser manuellement puis comprendre ce que l’on a reçut comme réponse

C’est pas vraiment adapté en fait, même si les développeurs ont mis en place des solutions pour faire marcher tout cela ( librairie paramiko/netmiko sur python par exemple, librairie ansible pour F5)

C’est pour cela que les constructeurs réseaux ont/commencent à implémenter des API sur leur équipements.

Les API sont des interfaces sur un serveur qui lui permette de facilement dialoguer entre serveurs, pour faire simple « je sais que je peux t’envoyer tel chose, et que tu vas m’envoyer tel réponse et tout cela de façon fiable »

Maintenant, par exemple, tu prend un serveur Linux, tu installe Python, tu vas voir chez le constructeur son API, et tu vois que pour avoir les statistique tu dois demander telle URL.

Avec Python, tu construit un petit script, qui va interroger chacun de tes équipements pour les statistique sur le nombre de connexions par exemple, et tu mets le tout dans un fichier qui sera envoyé par  mail.

Tu peux évidemment mettre à jour tes équipements, pour cela tu fais la même chose, tu vas sur le site du constructeur, et tu regarde « how to update configuration », ils te diront qu’il faut faire un « POST » avec tel valeur.

Car en effet, les API se basent la plupart du temps sur le protocole HTTPS.

Il faudra t’authentifier sur l’API, et tu auras le droit ensuite d’interroger, de mettre à jour etc tes équipements à travers cette API

Et donc bien sur pour dialoguer, il faut parler le même langage, il faut donc le structurer d’une certaine façon, cela se fait la plupart du temps en JSON.

Donc pour résumé, la nouvelle CCNA parle évidemment des « bases du réseaux » mais elle introduit maintenant la partie automatisation, de facon légeere il faut dire,

Evidemment, c’est quelque chose de très intéressant, cela implique de nouvelles compétences à acquérir, par exemple Linux et Python

Mais attention, quand on met à jour un équipement, « l’expérience réseaux » est très importante, car derrière une ligne de code Python, il y a un comportement qui va etre induit sur un ou des dizaines de switch.

Et cela peut faire tomber tout le réseaux

C’est pour cela, que même si en apparence, un « développeur » lambda peut faire ce travail, il pourra facilement faire un code, mais il a toutes les chances de crasher le réseaux.