We were pleasantly surprised by the way community appreciated gNMIc release. Thank you 🙏! That solidifies the fact that a well-formed, documented and easy to use gNMI tool was needed.

Now with gNMIc available to everybody its easy like never before to test gNMI implementation of different routing OSes. And in this post we will get our hands on Arista vEOS.

Despite the fact that gNMI is defacto the go-to interface for a model-driven telemetry collection, we, as a community, had no gNMI tool that was easy to install, pleasure to use, documented and pre-built for common platforms. Until now.

I am excited to announce the public release of gnmic - a CLI client and a collector that talks gNMI to your devices.

If you pick a random NetEng and ask them if they love NETCONF they would likely say “Nah”. The hate-hate love-hate kind of relationship with NETCONF mostly roots in its XML layer that one can’t swap out. But if we set the XML-related challenges aside, it will become clear that NETCONF is a very well designed management interface with lots of capabilities.

In this topic we will touch on the NETCONF’s subtree filtering capabilities.

gNMI Map

Lately I’ve been involved in project that required quite a deep understanding of OpenConfig gRPC Network Management Interface (gNMI). Going over the gNMI specification multiple times made me realize that I can’t fully build a mental map of all the messages and encapsulations without having a visual representation of it. So I’ve made one, lets see what it has to offer.

The power of a packet capture is boundless… Sometimes its indeed a pcap that can save you nights of troubleshooting, so being able to get one quickly and easily is an ace up a neteng sleeve.
In this post I’ll show you how I use Wireshark’s remote capture ability to sniff on packets running in EVE-NG without being need to install any custom plugins or packages from EVE.

Automation Is as Good as the Data Models is a chapter’s name in the great book titled “Network Programmability With YANG”. These days you won’t bedazzle anyone by just providing the set of YANG models for the flagship network products. The models alone, albeit a great step forward, do not guarantee that programmability will start flourish.
The automation tools leveraging YANG is often a missing link and in this post I am talking about the Nokia YANG tree and Path Browser tools which help both our internal automation squad and our customers to be more effective working with our YANG models.

I bet every one of you was in a situation when you bloody needed to expose some local resource over internet. Letting a remote colleague to look at your work, delivering a demo being off-VPN, or any other reason to have your service be reachable over Internet.

And it was never easy; corporate firewalls stand on-guard ensuring you can’t be agile and productive 😉

In this post I’ll share with you how I glue ngrok and fwd tools together to make my routers management interfaces exposed over Internet in a few clicks for free.

We can praise YANG as long as we want, but for an end user YANG is useful as the tooling around it and the applications leveraging it. Ask yourself, as a user of any kind of NETCONF/YANG application what was the last time you looked at a *.yang file content and found something that was needed to consume that application?
In a user role I personally never look at a YANG source, though, I look at the tree or HTML representation of YANG all the time; Thats is the YANG human interface for me.

And even in these human friendly formats you can’t find all the answers; for example, looking at the YANG tree, how do you get the XML data sample of a given leaf? Thats what we will discover in this post.

Its an engineers core ability to decompose a complex task in a set of a smaller, easy to understand and perform sub-tasks. Be it a feature-rich program that is decomposed to classes, functions and APIs or a huge business operation captured in steps in a Methods Of Procedure document.

In a network automation field where the configuration protocols such as NETCONF or gRPC are emerging, it is always needed to have a quick way to validate an RPC or Notification feature before implementing this in a code or a workflow.

This blog post is about a handy tool called netconf-console which allows you to interface with your network device using NETCONF quick and easy. And, of course, I packed it in a smallish container so you can enjoy it hassle-free on every docker-enabled host.

Not a single day goes by without me regretting I haven’t mastered any front-end technology like React/Angular or the likes. Why would a network engineer want to step into the game that seems orthogonal to its main area of expertise, one might ask?

Truth be told, I wasn’t born with an urge to learn anything that has javascript under the hood, but over the years, working within the network/backend silos, I realized, that being able to create a simple front-end service is a jewel that fits every crown, no matter what title you wear.

This tutorial is based on the task real task of building up a web interface (pycatjify.netdevops.me) for the pycatjify REST API service deployed as a serverless function. The end result is a simple, completely free and reusable Bootstrap based front-end boilerplate which can be used as a foundation for a similar task.