gnmic was the first opensource project that I’ve been part of that got widely adopted. As the maintainers of a public project, Karim and I were wondering when would we get the first external contribution.

To our surprise, the very first external contribution laid out the foundation to one of the most exciting features of gnmic - YANG-Completions.

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.

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.