Juniper – Page 2 – Gilbert MOÏSIO

16 août 201911 janvier 2020

Télémétrie Juniper

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

12 août 201911 janvier 2020

Nornir, Junos et Click

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

9 août 201915 août 2019

NetDevOps Accelerator

Dernière modification le 15 août 2019

NetDevOps Accelerator #1 Toulouse, le 22 juin 2019, a été l’occasion de concevoir un concept visant à accélérer l’adoption de l’approche NetDevOps dans le domaine du réseau. L’approche a mis en avant l’attitude « tous acteurs » et a proposé la fin de la théorie sur slide et des pseudos spécialistes qui n’en sont pas…

Articulée autour des partenaires HarryCow, Juniper Networks et Packet, cette journée a permis de créer une plateforme de simulation vQFX à l’aide de Vagrant afin d’exécuter des approches :

Python Netmiko
Juniper PyEZ
Juniper JSNAPy
Ansible
Salt

9 août 201912 août 2019

Salt Junos proxy

Dernière modification le 12 août 2019

Le Master étant prévu pour piloter plusieurs Minions, il n’est pas rare de les voir installés sur des serveurs différents. Pour un lab, il est acceptable d’installer le Master et le Minion qui va porter les Proxies sur le même serveur.

Chaque équipement à administrer avec Salt aura son propre Proxy.

J’ai suggéré un portage de « Syslog Engine » pour Python 3 qui n’est pas encore opérationnel. Lorsque je suis amené à utiliser Salt, c’est avec Ubuntu 16.04 et Python2.7, autant dire que je n’y touche que si je veux faire de l’Event-driven Automation.

Affaire à suivre…

9 août 201915 avril 2020

Ansible Juniper galaxy

Dernière modification le 15 avril 2020

Appliqué à Juniper Junos, il existe trois façon d’utiliser Ansible. Depuis la version 2.7.10, des modules réseau agnostiques sont disponibles. L’utilisation des modules cli_command et cli_config à la place de eos_config, ios_config, et junos_config permettent de réaliser des playbooks agnostiques.

Depuis la version 2.1, Ansible est livré avec de nombreux modules réseau spécifiques pour les constructeurs, dont ceux de Juniper s’appuyant sur la librairie Python ncclient, et supportés par la communauté Ansible. En version 2.8, les modules disponibles pour Junos sont les suivants :

Continuer la lecture

9 août 201911 janvier 2020

PyEZ

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

6 juillet 201911 janvier 2020

Switch virtuel vQFX

Dernière modification le 11 janvier 2020

Le switch virtuel Juniper vQFX, mis à disposition gratuitement pour les clients et les partenaires aux formats box, qcow2 et vmdk , peut être utilisé en mode light (Routing Engine uniquement) ou en mode full (Routing Engine et Packet Forwarding Engine). En mode full, le vQFX est constitué de deux machines virtuelles qui forment le Control Plane (RE) et le Data Plane (PFE).

Switch virtuel Juniper vQFX Light et Full

Les deux premières interfaces des VMs sont réservées pour le management Out-of-Band et l’interconnexion des deux VMs. L’interface em2 de la VM RE est réservée. En revanche, la VM RE supporte 12 interfaces supplémentaires pour le trafic Data Plane.

Continuer la lecture