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:

Go away or I replace you with a Makefile

I remember the first time I tried to get an open-source project compiled and deployed. The distribution of Linux at this point was Slackware. Build or installation instructions didn’t exist, and without handholding on IRC, it would not have been possible for me. That was 30 years ago, people in IRC were very self-selected, patient, and helpful. When you have skilled patient people in IRC and you can communicate what you did, what exactly failed, and what you would have expected - your learning experience is pretty impressive. Nevertheless, it does not scale well. People nowadays expect things to work with a click of a button. They are even not keen on reading clear instructions.

SNMP Proxy ... wait what?

Working with SNMP in 2025 is still a thing. Most hate it, but it’s sometimes the only thing you can use to get insights into the box you are working with. I want to shed some light on the SNMP proxy capability in Net-SNMP, it might be possible some people haven’t heard of it and might find it useful. In a nutshell, you can use Net-SNMP as a proxy to query information from another SNMP agent over an IP connection you can’t or do not want to query directly.

Hackathon on BGP monitoring using BMP in OpenNMS

We have seen people in the OpenNMS chat who started playing with the BGP monitoring protocol. I had some notes in our MediaWiki which doesn’t exist anymore. To provide some background I’ve resurrected my notes and republished the content. I had to tweak a few places to make it a bit more current. During the 5 years, OpenNMS has fixed bugs and maintained the functionality. The main intention of resurrecting the article is to give people some insights and background on what approach was chosen and why things are as they are today.

Building container images for OpenNMS

The previous article described how you can build and compile OpenNMS Horizon from source. This section explains how you build container images (OCI) from the source artifacts.

Deploy base image as foundation

Running OpenNMS Horizon core, Minion, or Sentinels in a container requires shared components. Some of them are a) the JDK base image, b) some useful tools, and c) JICMP, and JICMP6.

The JDK is shared with Core, Minion, and Sentinel. JICMP, and JICMP6 are required for Core and Minion. To manage these dependencies, we have a deploy-base image created which covers the main requirements running the Core, Minion, and Sentinel server processes. Getting an efficient size was a goal and a multi-stage build approach was chosen to address it. The fist

Dealing with secrets in OpenNMS Horizon

Dealing with secrets in a monitoring platform is a tedious task. The nature of monitoring systems is providing integrations in as many systems. Here is my mental model looking at the various ways for integrating OpenNMS. Especially having a 20 year old platform gives you some very own challenges. Talking about integration of monitoring systems, In OpenNMS Horizon/Meridian (OpenNMS for short), are some places where you have just one option, and some with various options. This article should help you to get an idea where you need to deal with secrets and credentials. The north/south areas serve monitoring purpose whereas the west/east directions address scaling topics in the context of volume, geographic or feature sets.

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.