Flexing the Network Device API Muscles with johann – Part 1: Introduction

Welcome to the four part blog series on the web-based network device monitoring tool – “johann”. Part one of the series serves as an introduction to johann. In part 2, you got a look behind the scenes of how I implemented the south-bound communication between the application and the network device with the network device API RESTCONF. Part 3 of the series focuses on the web-based application itself, with a focus on the Python Web-Framework Django. In part 4 of the series, we focus on johann deployment to production.

Let me tell you story: Back in 2019, I was new in my developer relations role at Cisco DevNet, and attended one of my first developer conferences in Austria as a speaker. In my session I was showing how network devices are configured with CLI and then, of course, introduced them to NETCONF and RESTCONF.

Directly after my session, I had an interesting discussion with a group of various software developers who have never laid hands on an enterprise networking switch at all. They could not believe that nowadays this kind of CLI and text-based configuration is still being used and did not understand why NETCONF/RESTCONF was not more popular. They mostly compared it with RPCs (Remote Procedure Calls), REST APIs or other interfaces where the whole communication was nicely defined and documented.

This is where I knew, I need to explore more the capabilities of the network device API, its limitations and maybe even spread the word about it among network engineers.

Well, here we are now!

At first, it started small and I only wanted to create a simple UI where any user can gain valuable information from many networking devices via RESTCONF. But it got bigger than expected: And with “it” I mean johann: Network Device Monitoring.

johann is a web-based network device monitoring tool specifically for Cisco IOS XE devices for now. It allows you to collect configuration and operational data of your networking devices in a structured way in one single database and display it on one dashboard.

What can you do with johann?

At first, the user needs to add their networking devices to johann. By simply putting the IP address, username and password, johann is requesting via RESTCONF (which needs to be enabled on the device) specific configurational and operational data of the devices and putting them into the local database.

After the devices have been added, the user can view all information in a structured way directly in the browser. There is also a page for every single device with detailed information and more importantly reports are being created based on the gathered data. As an example, one graph shows the total used IOS XE versions, the memory health status of all devices and if IOx is enabled or not.

But these are just small examples: Developers can extend the code and create various graphs based on various parameters (e.g. for configurations audits). This makes it very easy for the network admin to see on one dashboard if there are switches misconfigured or not.

And there are also some other tools included: You can enable RESTCONF on your networking device directly in the dashboard. This is done via the Python library netmiko. You can also see detailed logs and request the running configuration in JSON format.

Demo GIF: Get a short overview of how johann works

 

johann gives you stats of all your devices in nice graphs

What’s underneath johann?

If you are like me, you definitely would like to know what’s underneath johann. It is based on the Python Web-Framework Django. Via Python and the Python requests library, the configurational and operational data are requested from the RESTCONF interface of the device. The YANG modules and what data should be added to the SQLite database are pre-selected. If there are no parameters configured (for example no IP default gateway is set), then the value in the database will also be empty.

When devices are added or refreshed, a task is created. This is where celery and redis come into play. While the task is added to the celery task queue and the RESTCONF communication is established from there, the user can still browse around in the dashboard and gets task updates (current status and if the task is finished) from the celery task via Websockets using Django Channels. Redis as an in-memory data-storage is there to support the celery task queue and the Websocket communication.

Since Django is a web-framework, nginx is used to serve all static files (images, CSS-files, Javascript files etc.) to the user and is the point-of-contact for the web-user. To get data from the Django framework, SQLite database and establishing Websockets, daphne, an ASGI (Asynchronous Server Gateway Interface) server, is used. Therefore, nginx is also used as a reverse proxy to pass requests to daphne.

What to do with johann?

I hope that you enjoyed reading about the possibility of what you can do with the network device API NETCONF & RESTCONF with this web-based tool. But what’s next for you?

• Get inspired by johann: See johann as an inspiration of what you can do with the device APIs NETCONF/RESTCONF of networking devices (not limited to IOS XE). You can build your own johann or services around it. Remember, you can also change the device configuration with a web-based UI and gather data from other network devices using other YANG models.
• Use johann: If you need exactly a tool like that, just feel free to use it in your own lab or try it out with your IOS XE devices. For now, it’s read-only, but be careful when using it in your production environment.
• Extend johann: If you like johann and would like to extend its functionality, feel free to add your code. I tried to document my code as much as possible via inline comments. Some examples are: Creating more graph options, supporting more YANG models (not limited to IOS XE), creating an own network audit-section or even more!

This is just the beginning! After this introduction of johann, you will read in part 2 of this blog series how exactly you can get data via RESTCONF and the best practices. Stay tuned!

Additional resources

• Getting Data via RESTCONF – Flexing the Network Device APIs Muscles with “johann” Part 2
• Using Django with Celery & WebSockets – Flexing the Network Device APIs Muscles with “johann” Part 3
• Deploying Your Django App to Production – Flexing the Network Device APIs Muscles with johann, Part 4
• Download and test johann
• Watch a video demo of johann
• Visit the DevNet Model Driven Programmability Dev Center — Explore and learn about open management interfaces, NETCONF/RESTCONF/gRPC and YANG

 

---

We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

Twitter @CiscoDevNet | Facebook | LinkedIn

Visit the new Developer Video Channel