Gnmi Hours

[Skye Severy]

Release0.8.11:- Previous release introduced break for telemetry in Juniper due to inconsistency of communicated encoudings in Capabilities() and what is really supported in Subscribe().

Added new show_diff key to gNMIclient object (supported values print and get). When applied, it shows the changes happened to all keys following XPath from all arguments to Set() RPC at the network devices. It is so fair tailored to OpenConfig YANG modules as it uses some architectural principles of OpenConfig YANG module to re-construct XPath.Added an optional timeout to connect() method.Minor bug-fixing.Release 0.6.6:

Significant improvements in telemetry capabilities of the pygnmi. Now you can use subscribe2 method by simply providing the a corredponding dictionary at input and all modes (STREA, ONCE, POLL) are working correctly.Function telemetryParser is now automatically used inside subscribe2.Telemetry is now implemeted using threading.Added new unit tests with pytest and added code coverage with coverage.py.Release 0.5.3:

Added documentation in module regading supported the different paths naming conventions. Supported options: yang-module:container/container[key=value], /yang-module:container/container[key=value], /yang-module:/container/container[key=value], /container/container[key=value]Release 0.4.6:

LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.

The objective was to create an open-source tool to test that gNMI-based configurations and operations work as expected, using arbitrary paths and payloads. We proposed a tool for network operators and administrators to test and validate the exact gNMI configurations and operations they are using, and easily share the test and results with partners. This sounds very similar to UnitTests in software, where test methods and results can be shared and tracked.

It can be compared with other similar protocols like NETCONF or RESTCONF. A gNMI server implements 4 methods: Get, Set, Capabilities and Subscribe. For configuration automation, Set and Get methods are used. In these methods, what configuration to change is defined by the path to a tree-based data-model used, which is OpenConfig in this case, but could be any other.

Many network devices operating systems support gNMI interface and OpenConfig data models, usually for device telemetry collection. The idea is that network operators or administrators can set up vendor-neutral model-based automation and telemetry with an efficient transport protocol.

There is also the gRCP Network Operator Interface (gNOI), a suite of micro-services for executing operational actions, and gRPC Routing Information Base Interface (gRIBI), a service to inject routes in device's routing tables (reference)

I first wanted to experience configuring network devices using gNMI + OpenConfig manually, to better understand the problem. This programmatic interface is better suited for automation software, but before I started coding anything I needed to see it working with my own hands.

I started by checking which OpenConfig models corresponded to the configuration I needed to automate or check (e.g. IP address on an interface, hostname and NTP servers, static default-gateway route, BGP peers) and if these models were supported by the network devices. At this point, I had a minimal common denominator to start exploring gNMI. I looked for a gnmi client to start sending some Get requests, and choose gnmic (gnmi_cli and gnmi_cli_py are other possible options).

The OpenConfig models have a /config and /state container at different nodes of the model tree, where the configuration intent and the operational state are reflected. Likely, a change is first set at the /config path and will eventually be reflected in the /state path.

After enabling gNMI on the devices, I gathered the configuration and state of some of the configuration elements I was interested in, by using their path in the OpenConfig model. I used this chance to explore using paths (by making mistakes and getting response errors):

The payload of the gNMI messages is the JSON IETF representation of the OpenConfig model at the path requested. The deeper the path, the smaller the JSON payload. The responses I got from the devices helped me understand the OpenConfig Model (which is written in YANG, but I preferred reading in an HTML page). I tried editing some elements of the model (editing the JSON text) and configuring the device at different paths of the model. Again, by making mistakes and getting response errors, I tried how gNMI Set operations would and would not work.

Some devices took some time to reflect the configured state, which I checked using Get messages just after the Set (e.g. when setting radio channels in APs). Also, some errors came back when the device performed checks and was not able to accept the settings (e.g. when setting BGP Peers or enabling DHCP client on an interface). All these were great learnings before writing any code (testing > debugging).

After I played with gNMI using the cli, I followed the OpenConfig by Example tutorial. I then had configuration automation working with gNMI using both Python and Golang at the same time, I understood how it would be used for network automation. Both the OpenConfig models and the gNMI protobuf can be converted in code in several programming languages (e.g. Python, Go, Java), so you can implement your network automation system, or enhance your existing one with this mechanism. Also, network management tools could use gNMI as the southbound protocol.

Suppose you already have a gNMI-capable device automation system, or you are building one, so you know which OpenConfig paths and values are to be applied to several devices (e.g. fallback default static routes, SSIDs and VLANs, BGP peers, etc). You still have to figure out:

How do you test that the gNMI configuration works across software releases of the network devices, before they are upgraded? How do you test that all devices implement an OpenConfig model correctly, before you start using it in the automation system? How can you easily exchange the exact gNMI operations and results with partners, so you can collaborate on fixes? How could a network vendor or partner test that your gNMI operations work before shipping a new software release?

oc_config_validate attempts to solve these problems. oc_config_validate uses a YAML file as input with all the OpenConfig operations to test, and outputs the results to a text file that can be injected to a test-tracking system or simply parsed and read. Both these files are easy to exchange between testing parties.

For instance, in a lab environment with several network devices from different vendors, oc_config_validate runs can run periodically tests with operations on Wifi radio, static routes, bgp peers, etc. In an ideal state, all devices pass 100% of tests, after software upgrades or when new configurations are introduced. When not, a detailed error result indicates what failed.

Internally, oc_config_validate uses the Python unittest framework, making TestSuites and reporting the results in a similar way as major software unit testing frameworks. All this without writing any Python code (all is derived from the YAML test file). oc_config_validate includes the Python bindings of the OpenConfig models, using pyangbind, and can validate that a JSON payload of a gNMI call corresponds to the model pointed by the path. It will check both the model passed to the device in a Set request and the model received from the device in a Get request.

oc_config_validate is designed to be extensible in two ways: creating more YAML test files, and creating more Python test cases. The intention is to easily reflect and adapt to exactly how OpenConfig and gNMI are used in your use case.

Why Python? Good question, we could have chosen Golang. As Python is more widely used (Stackoverflow Insights 2021), it is a lower entry bar for contributors. Of course, if reality and community feedback tells us otherwise, oc_config_validate can be moved to Golang. Why YAML? We chose YAML over Protos, INI or JSON as tests input format because it is more human-readable for writing lists. Its indentation can be problematic, but easy to fix using a linter like yamllint.

oc_config_validate is a work in progress, and GitHub Issues and PullRequests are welcome. There are several ways the tool can be enhanced to accommodate more use cases, and you can drive priorities by signaling what is important, what are the pain points where oc_config_validate can help.

Use gNMI Capabilities method, to test that a given OpenConfig model is listed as supported, that JSON encoding is supported across the fleet of devices, etc. Use gNMI Subscribe method, to test that the returned JSON-encoded model is valid, that the timestamps change appropriately when using streaming mode, etc.

This was workingfine with gRPC version 1.17.2. We are trying to upgrade gRPCand other dependent modules used in our project. After upgrading to 1.33version, gnmi client send request is stuck in epoll_wait indefinitely. Here isthe back trace:

Prometheus is one of the most popular open-source monitoring and alerting systems, which scrapes and stores numerictime series data over HTTP. It has a very flexible query language, can send alerts via alertmanager to various platform and can be integrated easily with many open-source tools. For more details and use cases, please visit

The purpose of this article is to show how easy it is to deploy and configure Prometheus and Grafana andconfigure Arista switches to send telemetry states to Prometheus using TerminAttr ( EOS streaming telemetry agent )and one of the OpenConfig connectors that you can find on our official github page.

3a8082e126