17 avril 2014

Vous le savez tous, chez Nomios, nous sommes fans de Juniper et surtout de Junos. Non pas uniquement à cause des « commit confirmed » et autres rollback de configuration, mais aussi pour le côté richesse des fonctionnalités. Bien sur, on pourrait passer des heures à vous parler du fait qu’avec un SRX100, vous déployez un CPE Multiservices MPLS capable du meilleur. Mais non, aujourd’hui, on va plutot parler automatisation.

 

Aujourd’hui tout le monde parle SDN et actions automatiques sur le réseau piloté par un point central / Ajout de service à la volée / … Mais dans la plupart des cas, certaines actions peuvent être automatisées à moindre cout et permettant de faciliter la vie des exploitants du réseau.

Première étape : Les scripts embarqués sur les équipements

De son côté Juniper implémente depuis bien longtemps la notion de scripts Opérationnal / Event / Commit permettant d’adapter l’équipement à son environnement. Ainsi, un op script va permettre de créer des commandes d’exploitations supplémentaire. L’exemple présent içi ajoute une commande ILoveJunos qui affiche un message ainsi que le statut du routeur.

Les possibilités des event script ne s’arrête pas à ce genre de display, mais il est possible par exemple de reprendre les sorties de commandes en les remettant dans le format des commandes CISCO, ou encore de prendre l’ensemble des informations utiles pour tous les protocoles dans le troubleshoot d’une route …

 

https://i2.wp.com/3.bp.blogspot.com/-C14QxUSFfmo/UzUYZ8kqyDI/AAAAAAAFEww/IFLHlyfk5Q0/s1600/junos+script.PNG?w=525

 

Vu que le support des scripts est maintenant intégré dans Junos, pourquoi ne pas généraliser le concept et permettre le déclenchement d’un script sur évènement ou bien encore d’appliquer des scripts lors d’un commit pour vérifier / compléter les configurations. Qui n’a pas rêver de pouvoir couper une interface lors de la perte d’un peering BGP ou encore couper un port lorsque celui – ci joue à faire UP/Down trop souvent ?

 

Premier niveau d’automatisation qui certes nécessite de déployer les scripts sur l’ensemble des équipements, mais qui permet d’adapter un équipement Junos aux spécificités du SI et surtout de travailler sur le limitation des erreurs sur la production. Maintenant, comment faire pour piloter les équipements à distance ? Eh oui, aujourd’hui, on a plusieurs dizaines d’équipements à gérer et surtout tous ne sont pas du même éditeur.

 

Deuxième étape : Un Framework pour les piloter tous.

A l’heure actuelle, la grande question est : « Comment déployer un service rapidement et en limitant les risques d’erreur lors de l’implémentation ? » Pour y apporter un premier niveau de réponse, certains chez Juniper ont implémenté des framework permettant d’intégrer la gestion d’équipements Junos dans un SI déja en place.

On peut notamment nommer les plus connus :

  • Junos PyEZ : framework Python qui permet de gérer aussi bien la configuration que l’exploitation du routeur. Son gros avantage : être opensource et avec un développeur principal qui travaille à rendre le maximum de fonction sans devoir être développeur.
  • Implémentation Netconf en Ruby : Permet de scripter vos équipements directement avec le langage Ruby
  • et encore bien d’autres.

 

Et pour finir : s’intégrer dans les outils en place:

Bien sur on peu développer son SI, Bien sur on peut se créer des scripts, mais bien souvent il y a un existant et on doit s’intégrer avec. Pour cela, on va retrouver l’intégration de Junos dans les outils d’automatisation tels que Puppet, Chef ou encore Ansible.

 

Pour faire simple, Ansible est un outils permettant de pousser et de maintenir de la configuration sur des équipements réseaux et serveurs sans utiliser d’agent. Pour faciliter cette intégration, Juniper a fourni un module permettant de configurer les équipements lors du déploiement d’un service.

 

Chef et Puppet vise à réaliser la même chose que Ansible met en déployant un agents sur les machines. Du coup, Juniper a réalisé un module embarqué dans les équipements et permettant l’intégration de Puppet directement dans Junos

https://i2.wp.com/puppetlabs.com/sites/default/files/Solution_JuniperNetwork.jpg?w=525&ssl=1

 

Et bien sur, les modules logiciels sont bien présents pour Chef et Puppet.

 

Du coup, il devient simple d’intégrer un équipement Junos dans la chaine permettant de déployer un service : choisissez votre technologie, il est fort probable que Junos puisse y être intégré.

 

Bien évidement, nous avons traité dans cet article que la partie automatisation, mais il existe aussi des intégrations sur les solutions de SDN et de virtualisation telles que Openstack / Cloudstack et VMWare, mais ca on en parlera probablement dans quelques semaines 😉

 

Et surtout, si vous voulez discuter avec nous de ces sujets, n’hésitez pas à nous solliciter, le sujet est passionnant.

 

 

 

Partager :

Auteurs