Automatisation Juniper – Aéroport Nice Côte d’Azur

ACA - Aéroports de la Côte d'Azur

L’aéroport Nice Côte d’Azur est le deuxième aéroport de France avec 14.5 millions de passagers par an et un réseau de plus de 120 destinations, en majorité à l’international.

  • EVPN (Ethernet VPN)-VXLAN (Virtual Extensible LAN)
  • Underlay eBGP
  • Overlay iBGP
  • Centrally Routed Bridging (CBR) Overlay
  • 30 switchs Juniper QFX
  • 10 VRFs
  • 250 VLANs
  • 480 ports
  • 4000+ machines connectées
Grafana Aéroports de la Côte d'Azur
Monitoring Grafana / Prometheus en lab
Écosystème NetDevOps Aéroports de la Côte d'Azur
Écosystème NetDevOps ACA

Écosystème NetDevOps Aéroport Nice Côte d’Azur :

  • EVE-NG Pro
  • GitLab
  • Docker Swarm
  • GlusterFS
  • Juniper
  • Ansible
  • Python
  • Junos PyEZ
  • Robot Framework
  • Grafana
  • Prometheus
  • SNMP Exporter
  • Blackbox Exporter
  • gNMIc

Salt Junos Proxy Minion

Salt Juniper EVE-NG

Salt, de la société SaltStack, est un sujet dont je n’ai pas parlé depuis plus d’un an car le support de Python3 pour le « Syslog Engine » n’était pas fonctionnel et nécessitait d’utiliser un environnement de développement spécifique.

Entre le fait que ce problème soit réglé et que SaltStack ait été rachetée par VMWare, c’est le bon moment pour proposer un rappel sur cette solution qui ne manque pas d’intérêt pour faire du « Human-driven Automation », du « Event-driven Automation » et du « Machine-driven Automation » avec un outil structurant.

Salt utilise un modèle de communication serveur-agent, bien qu’il fonctionne aussi en tant qu’utilitaire de gestion de serveur unique autonome, et offre également la possibilité de s’exécuter sans agent via SSH.

Flexible Network Control
Source SaltStack

Le composant serveur s’appelle « Salt master » et l’agent s’appelle « Salt minion ». Le « Salt master » est responsable de l’envoi des commandes aux « Salt minions », puis de l’agrégation et de l’affichage des résultats de ces commandes. Un seul « Salt Master » peut gérer des milliers de systèmes. Salt communique avec les systèmes gérés à l’aide d’un modèle « publish-subscribe ». Les connexions sont initiées par le « Salt Minion », ce qui signifie que vous n’avez pas besoin d’ouvrir de ports entrants sur ces systèmes (réduisant ainsi le vecteur d’attaque). Le « Salt Master » utilise les ports 4505 et 4506, qui doivent être ouverts pour accepter les connexions entrantes.

Continuer la lecture de « Salt Junos Proxy Minion »

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

Librairie Python Robot Framework

Dernière modification le 7 décembre 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

Juniper 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

Librairie Juniper PyEZ - 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

Librairie Python Juniper 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.

Architecture de la librairie Juniper JSNAPy

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…