Webinar Python Université de Nice Côte d’Azur

Webinar Python IUT Nice

Dernière modification le 8 juillet 2020

Webinar Python pour l’Université de Nice Côte d’Azur organisé par Stéphane FRATI, Responsable parcours Licence Pro CyberDéf – Département Réseaux et Télécommunications (RT), le mercredi 24 juin 2020.

L’objectif du Webinar était de proposer une approche de l’automatisation de réseau avec le langage Python, en mettant en évidence un certains nombre de libertés apportées par l’utilisation de librairies spécialisées.

Webinar Université de Nice Côte d’Azur

Webinar Université Nice Côte d'Azur

Webinar pour l’Université de Nice Côte d’Azur organisé par Stéphane FRATI, Responsable parcours Licence Pro CyberDéf – Département Réseaux et Télécommunications (RT), le vendredi 5 juin 2020.

Outre une évaluation de connaissance dans le domaine du NetDevOps et plus particulièrement de l’automatisation réseau, l’objectif du Webinar était de proposer une présentation théorique de certains sujets parfois illustrés d’une démonstration visant à préparer une séance de travaux pratiques pour permettre aux étudiants de mettre en place leur propre plateforme de simulation et d’automatisation.

Free Webinar Ansible avec Juniper Networks

Free Webinar Juniper

Dernière modification le 21 avril 2020

Afin de profiter de la période de confinement pour améliorer les connaissances et revenir dans le circuit économique avec des méthodes encore plus efficaces, je vous propose une série de Webinars gratuits sur l’Automatisation Réseau.

Régulièrement, nous prendrons un sujet et nous le regarderons ensemble. L’objectif n’est pas seulement de participer de manière passive, mais aussi d’essayer soit même de le mettre en place en se faisant assister de la communauté présente dans le webinar.

Rejoignez la communauté Slack du NetDevOps Accelerator.

Continuer la lecture de « Free Webinar Ansible avec Juniper Networks »

Robot Framework

Robot Framework

Dernière modification le 28 mars 2020

Il existe de nombreuses solutions pour effectuer les tests unitaires TDD (Test Driven Development) dans le cadre des mises au point NetDevOps, mais Robot Framework est mon framework d’automatisation open source générique préféré pour effectuer les tests d’acceptation ATDD (Acceptance Test Driven Development). Ses capacités de test peuvent être étendues avec des librairies implémentées en Python ou en Java. Initialement, le framework a été développé par Nokia Networks. Aujourd’hui, il est sponsorisé par la Robot Framework Foundation.

Dans la mesure où on parle de « Network as Code » ou « Infrastructure as Code », c’est que l’on considère que tout ce qui est nécessaire pour activer l’infrastructure existe sous forme logicielle. Dans le monde du logiciel, les approches Agile et DevOps sont largement adoptées. On sait que les tests sont une partie importante de l’approche Agile pour la « Definition of Done » d’une « User Story ». Pour réaliser une « User Story », il est généralement nécessaire de la découper en tâches. Il n’existe pas qu’une seule façon de concevoir les choses, mais en ce qui me concerne, je considère que les tests qui valident une tâche doivent rester au plus proche de celle-ci. Il s’agit, le plus souvent, de tests unitaires. Si j’utilise Ansible pour réaliser la tâche, alors les tests permettant de dire que la tâche est bien terminée sont intégrés à ses Playbooks.

Continuer la lecture de « Robot Framework »

Automatisation Juniper Networks

Automatisation Juniper Networks

Dernière modification le 11 janvier 2020

Lorsqu’on aborde l’automatisation de réseau Junos, on peut avoir l’impression qu’il y des méthodes redondantes, tellement il y a de possibilités. Juniper Networks a intégré les concepts utilisés dans l’automatisation très tôt dans le système Junos et l’approche « Network as Code » est même ancrée dans l’ADN de l’entreprise.

Chacune des approches a sa raison d’être et de persister. On peut aisément penser que si des méthodes en avaient remplacé d’autres, du ménage aurait fait depuis longtemps dans le système Junos.

Voici ma vision sur la façon de répondre à certaines situations qui pourraient être rencontrées :

Continuer la lecture de « Automatisation Juniper Networks »

Junos REST API

Junos REST API

Dernière modification le 11 janvier 2020

Comme déjà évoqué, il existe plusieurs façons d’accéder aux informations et de les configurer sur des équipements Juniper Networks. Une de ces méthodes est de passer par les API REST (Representational State Transfer). Comme pour le CLI et NETCONF, les connexions REST, appelée parfois RESTful, se font au travers du process mgd. REST est considéré comme étant stateless car aucun contexte client n’est stocké sur le serveur entre les requêtes. Chaque requête contient toutes les informations nécessaires pour executer la requête et l’état de la session est conservé sur le client.

Junos REST API mgd
Continuer la lecture de « Junos REST API »

Tables and Views

Tables and Views

Dernière modification le 11 janvier 2020

Pour des constructeurs du monde de l’automatisation, accéder aux informations de configurations est souvent synonyme d’analyser les chaînes de caractères retournées pour les formater à l’affichage et y chercher des éléments ciblés. Par exemple, le module Python TextFSM a été mis au point pour permettre l’accès par programme aux informations renvoyées par l’interface de ligne de commande (CLI) des équipements réseau.

Dans le cas de Juniper Networks, Junos possède un ensemble complet d’API : API XML (accessible localement ou à distance en utilisant le protocole sécurisé NETCONF), API REST et API JET. Il existe donc plusieurs façons d’accéder avec certitude et de façon structurée aux éléments souhaités.

Les processus les plus importants pour l’automatisation de Junos sont les processus de service mgd et JET (jsd). Mgd gère les demandes d’automatisation impliquant l’API XML de Junos, YANG, l’API REST et certaines fonctions SNMP. Le processus de service JET (jsd) gère les demandes d’automatisation qui utilisent l’API JET (Juniper Extension Toolkit). Le processus de gestion (mgd) est au cœur de toute automatisation Junos basée sur NECTONF. L’interface de ligne de commande de Junos est également gérée par le biais de mgd.

Continuer la lecture de « Tables and Views »

JSNAPy

JSNAPy

Dernière modification le 19 août 2019

JSNAPy est un outil Open Source mis à disposition par Juniper. Il permet de valider la configuration d’un équipement et de comparer l’état d’une configuration avant et après une modification.

L’action peut être réalisée sur la configuration actuelle (snapcheck) ou sur le couple de configurations « avant et après » (PRE et POST).

Cet outil possède sa propre interface CLI pour être utilisé de façon autonome. Il est également possible de faire fonctionner JSNAPy à partir du modules Ansible galaxy juniper_junos_jsnapy ou directement à partir de scripts Python.

jsnapy --snapcheck postinstall -f start-2-1.yml
hosts:
  - device: localhost
    username: root
    passwd: Juniper
    port: 2222
tests:
  - test_interfaces.yml
tests_include:
  - test_interfaces_terse

test_interfaces_terse:
  - rpc: get-interface-information
  - item:
      id: ./name
      xpath: //physical-interface[normalize-space(name) = "em0"]
      tests:
        - is-equal: oper-status, up
          info: "Test Succeeded! oper-status is {{pre['oper-status']}} for interface {{id_0}}"
          err: "Test Failed! oper-status is {{post['oper-status']}} for interface {{id_0}}"
#!/usr/bin/env python3

import sys
from jnpr.jsnapy import SnapAdmin
from jnpr.junos import Device
from jnpr.junos.exception import ConnectError

# Variable for the Call to SnapAdmin
js = SnapAdmin()

# Config file to load
config_file = "start-2-1.yml"

# Call jsnapy With the Defined Configuration File
try:
  snapchk = js.snapcheck(config_file, "snap")
except ConnectError as err:
  print (
    'Cannot connect to device: {0}'
    .format(err)
  )
  sys.exit(1)
except Exception as err:
  print (err)
  sys.exit(1)
# Print results
for val in snapchk:
  print ('Tested on: {0}'.format(val.device))
  print (
    'Message: {0}'
    .format(
      val.test_details['get-interface-information'][0]['passed'][0]['message']
    )
  )
  print ('Final result: {0}'.format(val.result))
  print ('Total passed: {0}'.format(val.no_passed))
  print ('Total failed: {0}'.format(val.no_failed))
jsnapy --snap pre -f start-2-2.yml
jsnapy --snap post -f start-2-2.yml
jsnapy --check pre post -f start-2-2.yml
hosts:
  - device: localhost
    username: root
    passwd: Juniper
    port: 2222
tests:
  - test_no_diff.yml
tests_include:
  - test_interfaces_terse

test_interfaces_terse:
  - rpc: get-interface-information
  - iterate:
      xpath: //physical-interface
      id: './name'
      tests:
        - no-diff: description
          err: "Test Failed! description for <{{id_0}}> got changed, before it was <{{pre['description']}}>, now it is <{{post['description']}}>"
          info: "Test succeeded! description for <{{id_0}}> did not change, before it was <{{pre['description']}}>, now it is <{{post['description']}}>"

J’ai demandé une amélioration car le nom des fichiers snapshots est constitué avec l’adresse IP mais pas avec le port, et il n’est pas possible de changer le nom du fichier depuis un playbook Ansible utilisant juniper_junos_jsnappy. Lorsque JSNAPy est utilisé en environnement de simulation Vagrant, tous les devices ont la même adresse IP, ce n’est que le port qui les différencient. A suivre…

Télémétrie Juniper

Juniper Télémétrie

Dernière modification le 11 janvier 2020

Le modèle traditionnel de monitoring de réseau est basé sur un modèle dit « pull », utilisant SNMP et CLI pour interroger périodiquement les équipements du réseau. Ces méthodes ont des limites inhérentes en matière d’évolutivité et sont gourmandes en ressources, en particulier lorsqu’un grand nombre de métriques sont interrogées à une fréquence très élevée.

JTI (Junos Telemetry Interface) contourne le problème et élimine le besoin de scrutation, en utilisant plutôt un modèle « push » pour transmettre les données de télémétrie à un collecteur de manière asynchrone sous forme de flux. Cette approche est beaucoup plus évolutive et prend en charge la surveillance de milliers d’objets dans un réseau avec une résolution granulaire.

Cependant, la collecte de données de télémétrie n’est pas une tâche aisée, car elle implique généralement trois types de fonctions :

Continuer la lecture de « Télémétrie Juniper »

Nornir, Junos et Click

Nornir Junos

Dernière modification le 11 janvier 2020

Même si Ansible est très bien pour faire du Human-driven Automation face à des équipements Juniper, je trouve gratifiant et plus pratique de développer directement en Python. Comme je l’ai déjà expliqué, j’utilise le protocole NETCONF simplifié par le micro framework PyEZ. Je me sers de PyEZ de façon transparente au travers de NAPALM, lui même piloté par le framework Nornir.

Lorsque l’on écrit des scripts, il peut rapidement y en avoir une grande quantité très proches les uns des autres et qui ne font, chacun, qu’une seule fonction.

C’est pour cette raison, que je rajoute le package Python Click qui permet de réaliser des interfaces CLI (Command-Line Interface) enrichie, de manière à limiter le nombre de scripts.

Prenons comme exemple un script dont l’objectif serait de faire des napalm_get et napalm_configure avec un CLI simplifié.

Continuer la lecture de « Nornir, Junos et Click »