Reversing the dial: the many faces of gNMI dial-out

Ask five vendors how they do “gNMI dial-out” and you’ll get five different answers. You’ll find everything a custom gRPC service here, an opaque protobuf envelope there, a generic tunnel over on the standards track. When I started to work on gNMI dial-out in nl6, I wanted the whole map, not just the one corner I’d already implemented. The work with the nl6 simulator forces me to understand the landscape.

The punchline up front, because it reframes everything: gNMI has no dial-out.

gNMI dial-in vs. dial-out – Who picks up the phone

I work with people who build network monitoring systems. SNMP Traps, NetFlow and IPFIX, BMP — in all of them the device pushes and the collector listens. And in all of them the device reaches out: nothing has to connect into the fleet.

Then you deploy gNMI dial-in and a colleague asks why this one stream connects the other way around. Good question, and it took me a while to give a honest answer.

Streaming telemetry with gNMI

This document describes how you can set up a lab environment for testing gNMI using a virtual HPE Juniper router running Junos 24.2 R1-S2.5. It shows how you can collect metrics for interfaces and CPU utilization collected with OpenNMS. This isn’t something I do every day, so I just preserve this here for my future self and the ones who want to get up to speed a bit quicker.

What you will learn

• Enable gNMI over gRPC with sensors on a HPE Juniper router
• Verify the gRPC connections and configuration
• Enable OpenNMS Horizon to subscribe to gRPC streams for sensor data
• Set up TLS on gRPC using a self-signed certificate authority
• Visualize the collected data in Grafana

Limitations

• Streaming telemetry can only be configured from the OpenNMS Core instance, see enhancement NMS-18064
• Metric labels for network interfaces are right now just resource id strings

Before you begin

You need the following environment to get a lab running: