Étiquette : python

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.

Continuer la lecture de « Junos REST API »

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…

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 »

Dernière modification le 11 janvier 2020

PyEZ, de son vrai nom junos-eznc, est un micro framework proposé en Open Source par Juniper afin de faciliter l’accès, à l’aide du protocole NETCONF, aux équipement tournant Junos . Comme le montre l’image, indépendamment de l’accès direct par le langage Python, ce micro framework est utilisé par d’autres outils comme Ansible, Salt ou JSNAPy.

Junos PyEZ est un package jnpr.junos qui contient les modules suivants :

• device: Defines the Device class, which represents the device running Junos OS and enables you to connect to and retrieve facts from the device.
• exception: Defines exceptions encountered when accessing, configuring, and managing devices running Junos OS.
• factory: Contains code pertaining to Tables and Views, including the loadyaml() function, which is used to load custom Tables and Views.
• facts: A dictionary-like object of read-only facts about the device. These facts are accessed using the facts attribute of a Device object instance.
• op: Includes predefined operational Tables and Views that can be used to filter output for common operational commands.
• resources: Includes predefined configuration Tables and Views representing specific configuration resources, which can be used to programmatically configure devices running Junos OS.
• transport: Contains code used by the Device class to support the different connection types.
• utils: Includes configuration utilities, file system utilities, shell utilities, software installation utilities, and secure copy utilities.

Continuer la lecture de « PyEZ »