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.

Two Claude Accounts, Revisited

A while back I wrote about using two Claude accounts side by side. A private subscription and a corporate team account, two config dirs and a pair of shell aliases so the tokens don’t bleed into each other. That part still works fine. But after living with it for a few months, I learned where it falls short, so here is the grown-up version.

Two setups drift apart

The aliases only solved which account pays. They did nothing about how Claude behaves. Each config dir grew its own CLAUDE.md, and the moment you maintain two of anything by hand, they drift. I’d tighten a commit convention in one account and forget the other. The work account learned a guardrail the private one never got. What I really wanted was the same baseline everywhere, conventional commits, SHA-pinned GitHub Actions, license headers, no matter which hat I’m wearing.

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.

Blitsbom, browser-only SBOM viewer

I had to scratch one of my itches. I have to work with SBOMs and I couldn’t find something, so I’m announcing blitsbom — a browser-only SBOM viewer. Software Bills of Materials are everywhere now. Procurement asks for one. Compliance wants one filed. A regulator’s auditor will, at some point, want to look at one. The trouble is that the moment you actually want to read an SBOM — to skim what’s in a build, see which components are copyleft — your options are oddly bad. You either ship the file off to a SaaS scanner, install a heavyweight platform, or squint at 280,000 lines of JSON in your editor.

CoolModFiles, but not just random

I’ve been a quiet user of CoolModFiles.com for years. It’s a tiny web player that grabs a random MOD file from modarchive.org and plays it. No login, no library, no algorithm — just a play button and a wave of nostalgia from the Amiga and PC tracker scene. The README says “no black magic involved” and that’s exactly the appeal: a digital amplifier for a corner of the demoscene most people never knew existed.

Using Two Claude Accounts Side by Side

Just something a few might be interested in. I’m in a fortunate situation where I have a private Claude account and also signed in to a corporate Claude team account.

I would like to make sure I spent the tokens from the work subscription only on work-related items and the tokens from my private account on my own stuff. What works for me pretty well is having two Claude config dirs and a shell alias like this:

How Docker Broke the Internet for Me

We have seen two major outages in the last weeks caused by AWS and Azure networking issues. Both outages had a significant impact on services running in the cloud and affected a large number of users. The self-hosting people were laughing about it, but some got struck with the recent Docker 29.0.0 release. It simply increased the minimal API version from 1.24 to 1.44.

This change broke Traefik and some tooling, like the testcontainers-java. The maintainers of Traefik already released a fix, and probably created some stress for them. A lot of issues poped up in their GitHub repository, like this one https://github.com/traefik/traefik/pull/12256. I felt sorry for them, many users use their stuff - including me - to drive HTTP/HTTPS traffic to their websites. It was great to see how quickly shared workarounds. The Traefik maintainers were able to provide and ship a fix in a new release very quickly. All you need to do is upgrade to 3.6.1, and you are good to go again.

macOS with Apple Silicon and x86-64-v3 support

I’m maintaining container images in the OpenNMS ecosystem. My local machine is a Mac with Apple Silicon. While I was upgrading some base images using RHEL UBI 10 / CentOS 10 images, I noticed the following error message.

0.112 Fatal glibc error: CPU does not support x86-64-v3

That happens if you try to run on an emulated x86 architecture running on ARM. After some investigation, I’ve found an article in the Red Hat developer forum talking about upgrading the Microarchitecture level from v2 to v3. The problem introduced is that v3 isn’t supported. I’m using Orbstack and you can reproduce this problem simply running the following docker command.

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:

Hello Containerlab with Orbstack

I still remember signing up on DockerHub 11 years ago. Learning how to build container images on real world projects is definitely a plus. Having a software and some use cases in the back of your mind, helps you to achieve things quicker and with some purpose. I’ve started to work with containerlab to build some network test environments mainly for three use cases:

• Layer 2 network topologies for network monitoring tests using LLDP, CDP and Bridge-MIB
• Routing topologies with protocols like BGP, OSPF or IS-IS in general
• Some vendor specific network gear for monitoring with SNMP and streaming telemetry

Playing with OpenNMS from this perspective opens some use cases around Netflow, IPFIX, BGP monitoring, and SNMP in general. I was using Docker4Mac for a very long time. At some point in time I have switched to colima which was slim and easy to use. With switching to ARM on my Mac it got a bit more complicated.