Skip to content

pwoconnor/eNMS

 
 

Repository files navigation

status
master Build Status Coverage Status
develop Build Status Coverage Status

Introduction

eNMS is an open source web application designed to help automate networks graphically.

eNMS

It encompasses the following aspects of network automation:

  • Configuration management: commit/rollback of a configuration via NAPALM.
  • Netmiko scripting: using netmiko to push a configuration, or display the result of a set of commands.
  • Ansible support: sending and managing ansible playbooks.
  • Workflows: Netmiko, NAPALM and Ansible scripts can be combined together graphically to define a workflow.
  • Scheduling: any task can be scheduled to start and end at specific times, periodically or not.

While network automation traditionally requires scripting skills, eNMS provides a way to automate networks graphically, in a few simple steps:

  • Creation of the network.
  • Visualization of the network on a world map (geographical view), or via a force-based algorithm (logical view).
  • Creation of scripts and workflows.
  • Scheduling of the task from the geographical or logical view.

1. Network creation

Nodes and links can be created either one by one by specifying all properties manually, or all at once by importing an Excel spreadsheet. Once created, all objects are displayed in a sortable and searchable table, from which they can be edited and deleted.

The dashboard provides a graphical overview of all objects with dynamic charts.

Object creation

Try it out yourself: Object management, Dashboard

Relevant part of the doc: Object creation

2. Network visualization

Two visualizations are proposed:

  • Geographical view: display the network on a world map in 2D or 3D, with Open Street Map or Google Map.
  • Logical view: display the network in an aesthetically-pleasing way via a force-based algorithm.

Views can be filtered to display only a subset of the network. A filter is a combination of values (or regular expressions) for each property: it defines whether an object should be displayed or not.

You can display the property of an object from both views, and start an SSH session to a device.

In the following example, we create a first filter with the regular expression france|spain for location to filter all objects that are not in France or in Spain, and a second filter with the value IOS-XR for Operating System to filter all nodes that do not have the IOS-XR operating system. We use these filters on both views, then start an SSH session to one of the router.

Network GIS visualization

Try it out yourself (double-click on a node to display its properties): Geographical view, Logical view, Filters

Relevant parts of the doc: Geographical view, Logical view, Filters, Bindings

3. Creation of scripts and workflows

The following types of script can be created:

  • Netmiko configuration: list of commands to configure the device (plain text or Jinja2 template).
  • Netmiko show commands: list of “show commands” which output is displayed in the task logs.
  • Netmiko validation: list of command which output must contain a specific pattern (used in workflows).
  • NAPALM configuration task: partial or full configuration (plain text or Jinja2 template) of the device.
  • NAPALM getters: list of getters which output is displayed in the task logs.
  • Ansible playbook: send an ansible playbook with optional arguments.

Scripts can be combined to form a workflow. A workflow is a directed graph which vertices are scripts. There are two types of edge in a workflow: success edge and failure edge. The success edge (resp. failure edge) indicates which path to follow in the graph if the source script was successfully executed (resp. failed).

In the following example, we create a workflow to configure a VRF on Cisco IOS. Our workflow is made of 4 scripts:

  • create_vrf: uses NAPALM to configure a new VRF on the router (via Load merge).
  • NAPALM Commit: commits the newly configured VRF.
  • validate_vrf: uses Netmiko to verify that the state of the router is consistent with what is expected.
  • NAPALM Rollback: use NAPALM to rollback the configuration if the previous validation fails (validate_vrf script).

Workflow creation

Try it out yourself: Script creation, Script management, VRF configuration workflow (double-click on a script to display its properties)

Relevant parts of the doc: Scripts, Workflows, OS upgrade workflow,

4. Scheduling

Once a script / workflow has been created, a task can be scheduled from the graphical view. The targets are selected graphically. Filters can be used to schedule a task on a specific subset of device.

The following parameters are available:

  • Frequency: the task is executed periodically. This is especially useful for tasks that pull some information from the device, i.e netmiko show commands / NAPALM getters tasks.
  • Start date: instead of running the task immediately, the task will start at a specific time.
  • End date: used for a periodic task to stop at a specific time.

In the following example, we schedule the configure_vrf workflow created at the previous step. All scheduling fields are left empty: the workflow is executed immediately. The scripts of the workflow are executed one by one, except for NAPALM Rollback as the validation step does not fail.

Workflow creation

Try it out yourself (Scheduling button): Geographical view, Logical view, Calendar

Relevant part of the doc: Scheduling

5. Comparison of the results

The results of a periodic task can be compared between two different times, devices or tasks. eNMS displays a dynamic line-by-line diff of the outputs.

In the following example, we schedule two periodic tasks:

  • a task that will periodically run show interfaces on a router with Netmiko.
  • a NAPALM getter task that will periodically retrieve the output of NAPALM get_interfaces_counters getter.

We can see in the comparison how counters increase through time for both tasks.

Workflow creation

Try it out yourself: Task management

Relevant part of the doc: Task results

Miscellaneous

  • eNMS can act as a TACACS+ authentication server: upon authentication, a request will be sent to the server to check the credentials and log in the user.
  • eNMS can act as a Syslog server: all logs are stored in the database, and can be filtered with regular expressions. Eventually, the idea is to use the logs for event-driven automation, i.e trigger the execution of a script upon receiving a specific type of log.
  • From the geographical view, networks can be displayed on the earth with a 3D map. They can also be exported to Google Earth.

Getting started

(Optional) Set up a virtual environment

1. Get the code

git clone https://github.com/afourmy/eNMS.git
cd eNMS

2. Install requirements

pip install -r requirements.txt

3. Set the FLASK_APP environment variable

(Windows) set FLASK_APP=app.py
(Unix) export FLASK_APP=app.py

4. Run the application

flask run --host=0.0.0.0

6. Create an account and log in

Run eNMS in a docker container

1. Download & run the container

docker run -d -p 5000:5000 --name enms --restart always afourmy/enms

3. Create an account and log in

Contact

For any feedback, advice, feature request, join us on the Network to Code slack (channel #enms)

Other projects you might be interested in

  • Flask Gentelella: The Flask/Bootstrap template eNMS is built upon.
  • pyNMS: A PyQt software for network simulation and optimization.
  • SWAP: A solver for the Wavelength Assignment Problem in optical networks.

About

A vendor-agnostic NMS for graphical network automation

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages

  • Python 39.1%
  • CSS 22.8%
  • HTML 22.0%
  • JavaScript 15.9%
  • Mako 0.1%
  • Dockerfile 0.1%