Posts on ForwardingPlane.net

piccolo-perf - a perfSONAR-lite for routers and SBCs

Sun, 02 Aug 2026 00:00:00 +0000

I have a soft spot for perfSONAR . It’s the gold standard for research and education network performance measurement, and if you run a network that touches ESnet, Internet2, or any of the big R&E backbones, you’ve probably got a perfSONAR node (or ten) somewhere. The problem is that perfSONAR is heavy. It wants a full OS, a stack of services, and real resources. That’s fine for a dedicated measurement box and that has served perfSonar well for 20 years, but it’s a non-starter for a router, a Raspberry Pi at a remote site, or anything else you’d call “constrained.”

That gap is exactly what piccolo-perf is going after. It’s a single static Go binary, no runtime dependencies, that gives you TWAMP-Light, TCP bandwidth, traceroute, MTU discovery, and DNS latency measurements, plus an agent mode that turns a fleet of these into a lightweight distributed mesh - InfluxDB and Prometheus included. Dual stack throughout, which matters to me more than it probably should. Honestly, I have been working on this for 15+ years, from trying to run OWAMP on a rpi1, to helping distribute mac minis for perfSonar tools into campuses, to even running lightweight versions of the toolkit on actual L3 switchines in the early days of virtualized NOSs'. This project has been a labor of love and with my recent endeavor to teach myself golang, I thought “why not give it a try with this”? The results are surprisingly useful.

The measurement set:

twamp - RTT, jitter, and packet loss via TWAMP-Light (RFC 5357 §5). No TCP control session, pure UDP test packets, so it’s cheap to run and interoperable with other TWAMP-Light endpoints.
bw - TCP throughput, either a native Go implementation or iperf3 if it’s present on the box.
trace - per-hop RTT and path topology via ICMP TTL/HopLimit probing, IPv4 and IPv6.
mtu - effective path MTU via ICMP binary search (DF-bit on v4, Packet Too Big on v6). Useful for finding where a WireGuard tunnel or a double-encapsulated path quietly knocked your MTU down - very common in managed-service-paths.
dns - A successor to DNS test resolver latency and success rate, independent of the system resolver.
agent - runs all of the above on a schedule, reflects TWAMP for peers, and ships results to InfluxDB and/or exposes them as Prometheus metrics.

Anything that needs raw sockets (mtu, trace) degrades gracefully without CAP_NET_RAW rather than failing outright - it just reports skipped=true. That’s a small detail, but it’s the kind of thing that tells you someone has actually run this on a box they don’t have root on. I’d be open to better ways to handle that.

Getting it running is a one-liner:

/bin/sh -c "$(curl -fsSL https://raw.githubusercontent.com/retecolo/piccolo-perf/main/install.sh)"

and a one-shot test looks like this:

piccolo-perf twamp -mode client -server 2001:db8::1

[TWAMP-Light-Client] Starting TWAMP-Light test to 2001:db8::1 (count=10 interval=1s timeout=5s padding=0)
[TWAMP-Light-Client] seq=1 RTT=0.823ms
...
[TWAMP-Light-Client] === TWAMP-Light Test Statistics ===
[TWAMP-Light-Client] Packets sent:     10
[TWAMP-Light-Client] Packets received: 10
[TWAMP-Light-Client] Packet loss:      0.0%
[TWAMP-Light-Client] RTT min/avg/max:  0.778 / 0.812 / 0.857 ms
[TWAMP-Light-Client] Mean jitter:      0.018 ms

The part I find more interesting than the one-shot CLI use is agent mode, and this harkens back to the inspiration for this peoject, perfSonar. Point a handful of hosts at a config server serving a JSON topology file, and each host stands up a TWAMP reflector, a bandwidth sink, and per-measurement schedulers, then pushes results upstream:

┌─────────────────────────────────────────┐
│            Each Probe Host              │
│  piccolo-perf agent                     │
│  ├── TWAMP-Light reflector (UDP)        │
│  ├── BwServer (TCP sink, port 5201)     │
│  ├── Per-measurement schedulers         │
│  ├── Config poller (HTTP, live-reload)  │
│  ├── InfluxDB writer                    │
│  ├── Prometheus /metrics                │
│  └── Local JSONL resilience store       │
└──────────┬──────────────────┬───────────┘
           │ pull config      │ push metrics
           ▼                  ▼
  ┌──────────────┐    ┌──────────────┐
  │ Config Server│    │   InfluxDB   │◀─── Grafana
  └──────────────┘    │  Prometheus  │
                       └──────────────┘

Topology can be full mesh (every host probes every other host) or hub-and-spoke, which is the more realistic shape for most of us - a handful of spokes reporting back to a hub instead of an N² mesh. There’s also a local JSONL ring buffer for intermittently-connected edge devices, so a probe that loses its uplink keeps measuring and replays results once connectivity comes back instead of just dropping data on the floor.

Where this actually fits

A few use cases jump out:

IPv6 test pods and lab networks. If you listened to IPB173 or any of the recent IPv6 Buzz episodes on lab builds, this is a natural fit for exactly that kind of environment - dual-stack RTT, jitter, and MTU measurement without standing up a perfSONAR node for every pod. Hey James, lets test this out =)
CPE and branch office monitoring. Since it compiles to a static binary across amd64, arm64, arm, mips, ppc64le, and riscv64, it’ll run on the kind of small router or SBC that lives at a remote site where you have no business installing a full measurement stack.
VPN and tunnel path MTU troubleshooting. The mtu subcommand’s binary search is a fast way to confirm whether a WireGuard or other tunnel is silently truncating your effective MTU, without reaching for tcpdump and doing the math by hand.
A perfSONAR-adjacent mesh on a budget. Agent mode with hub-and-spoke topology and Grafana on top gets you a reasonable approximation of a perfSONAR mesh dashboard for a fraction of the deployment overhead, which is appealing if you want visibility into a network that doesn’t justify (or fit) the full perfSONAR toolkit.

It’s early days for the project, but the design choices - graceful degradation without root, IPv6 treated as a first-class citizen rather than an afterthought, and a resilience store for flaky links - suggest someone building this against real constraints rather than a whiteboard. Worth a look if smokeping and perfSONAR are two ends of a spectrum you’ve been missing the middle of.

IPB 204 - Tayga and IPv6 Translation

Thu, 23 Jul 2026 00:00:00 +0000

Andrew Palardy joins the hosts to discuss how Tayga, the open-source NAT64 daemon for Linux, is being updated to ensure it is up to date with all the current RFCs. The discussion covers RFC compliance updates and UDP checksum fixes for resolving connectivity problems, plus new eBPF CLAT support arriving in NetworkManager to provide automatic CLAT functionality.

Have a listen:

Podcast link: IPB204: Tayga and IPv6 Translation

Show links:

Tayga (GitHub)

Andrew Palardy on YouTube

Andrew Palardy’s Website

IPv6 - Why You Should Care

Wed, 22 Jul 2026 00:00:00 +0000

I had the opportunity to speak at the Chicago Network Operators Group conference for CHI-NOG 13. As one may imagine, I talked about IPv6, and why folks should care. Now, you’re probably thinking “yeah, yeah, IPv6 has been almost here for 20 years”, and I’d move along and not try to convince you otherwise. However, this talk was slightly different - the whole point was to acknoledge that yes, it’s taking a long time. Yes, enterprises are the long pole in the tent. But no, it’s not almost here. It’a already here, and it’s been here for a decade. Where it isn’t is in the enterprise - and that’s not really a surprise. the talk was very well received, garnering probably the most flattering write up of any talk I have ever given, and by a highly technical author that was in the front row of the talk. you can read that here , which I highly encourage you to do.

If you’re interested, the talk is available on youtube . It’s 30 minutes and I would argue that it makes a pretty compelling argument, if i do say so myself =)

IPB 203 - The Death of NAT

Thu, 25 Jun 2026 00:00:00 +0000

Network Address Translation (NAT), a foundational element of IPv4, faces critical reassessment as IPv6 deployment shifts the landscape. Ed and Tom evaluate the evolving role of NAT, questioning whether traditional translation models remain necessary when stateful packet inspection offers more robust, transparent security solutions.

Have a listen:

Podcast link: IPB203: The Death of NAT

Show links:

“Fanboy” series – IPv6 and NATs

IPB 202 - How to Get Hands-On IPv6 Deployment Experience

Thu, 11 Jun 2026 00:00:00 +0000

The episode explores gaining practical IPv6 experience through hands-on deployment. Guest John Osmon discusses setting up a personal IPv6 lab environment, including low-cost home lab options and how this experience has increased his confidence in tackling IPv6 projects.

Have a listen:

Podcast link: IPB202: How to Get Hands-On IPv6 Deployment Experience

Show links:

“Where in the contract does it say you can’t NAT IPv6?"

“So, you want to try IPv6?"

IPB 201 - The Never-Ending Prefix Debate: Revisiting Best Current Practices

Thu, 28 May 2026 00:00:00 +0000

Today’s conversation centers around a new Best Current Practices (BCP) RFC draft written by Jordi Palet Martinez. Our hosts explore the document for service providers and enterprises, including prefix sizing for point-to-point links, the pros and cons of numbering choices, and best practices for prefix pool allocation.

Have a listen:

Podcast link: IPB201: The Never-Ending Prefix Debate: Revisiting Best Current Practices

Show links:

IPv6 Prefix Assignment to End-Sites

IPB 200 - Yes, IPv6 Is Complicated. IPv8 Won't Help

Thu, 14 May 2026 00:00:00 +0000

Why is IPv6 so much more complicated than IPv4? Could a newer version such as IPv8 be the solution? Guest Brian Carpenter joins our hosts to explain that many of IPv6’s complications are mathematical necessities. They point out that IPv6 has a 30 year head start on any IPv8 proposal that would struggle with many of the same issues. They also discuss features like automatic address configuration and the slow but inevitable global adoption of IPv6.

Have a listen:

Podcast link: IPB200: Yes, IPv6 Is Complicated. IPv8 Won’t Help

Show links:

“Why is IPv6 so complicated?"

Book6 – An open source book on IPv6

IPB 199 - Developing IPv6-Friendly Code

Thu, 30 Apr 2026 00:00:00 +0000

Tom Coffeen and Nick Buraglio welcome Fern Cummings to talk about developing code for IPv6. Fern argues that moving to IPv6 restores end-to-end connectivity, which reduces complexity for developers without the need for “ridiculous hacks” caused by IPv4 NAT. The discussion offers practical advice on avoiding common developer traps, and covers financial benefits such as reduced logging costs and improved security.

Have a listen:

Podcast link: IPB199: Developing IPv6-Friendly Code

IPB 198 - IPv6 Privacy and Temporary Addresses

Thu, 16 Apr 2026 00:00:00 +0000

Today our hosts discuss IPv6 Privacy and Temporary Addresses to clarify how address provisioning can potentially work for host operating systems. The discussion covers the difference between permanent and temporary privacy addresses, their uses, and how interface identifiers are assigned to hosts.

Have a listen:

Podcast link: IPB198: IPv6 Privacy and Temporary Addresses

IPB 197 - SLAAC and the End of DHCP?

Thu, 02 Apr 2026 00:00:00 +0000

Today our hosts discuss the essential role of Stateless Address Autoconfiguration (SLAAC) in successfully deploying an IPv6-mostly network. SLAAC is required to assign a unique IPv6 address to the Customer-side Translator (CLAT), which allows devices to operate on IPv6. However, enterprise operators might prefer using DHCPv6 for network tracking and accountability, potentially trapping them in complex dual-stack environments.

Have a listen:

Podcast link: IPB197: SLAAC and the End of DHCP?

Show links:

RFC 9686: Registering Self-Generated IPv6 Addresses Using DHCPv6

IPB 196 - Is End-to-End Connectivity the Right Goal?

Thu, 19 Mar 2026 00:00:00 +0000

One of the early design principles of the Internet was end-to-end connectivity: that is, every device on the Internet would be publicly addressable, and every device could share its resources or provide services. The hosts examine whether this foundational principle remains realistic for IPv6, discussing its historical erosion in IPv4 and the IETF’s continued adherence to it.

Have a listen:

Podcast link: IPB196: Is End-to-End Connectivity the Right Goal?

Linkwarden with docker compose and nginx proxy manager

Thu, 12 Mar 2026 00:00:00 +0000

[Linkwarden(https://github.com/linkwarden/linkwarden) is a tool for better managing bookmarks. If you’re nything like me, you keep 1000 browser tabs open across a series of profiles, with full intention of revisiting them later, and then never do. A colleague shpoed me linkwarden and I was interested straight away. I did have a few hangups, however:

I don’t want to rely on a cloud service if I don’t have to
I prefer to control my own content
I am not a big fan of docker, which is required for self hosting

I got over the docker hangup since it wasn’t really an option to do any other way and got straight to it. Very quickly I ran into the near-universal issues I have with docker:

poor understanding or lack of attention of networking by the developers (this needs to run over IPv6 for me to use it)
spotty documentation for running this securely via a SSL enabled web service

As I have done with other services that require docker, I went to nginx proxy manager. This container is a nice front end for proxying services via SSL / NGINX, and is far easier to wrestle than something like Traefik.

After much fighting of the docker compose file I ended up with this, which works.

services:
  postgres:
    image: postgres:16-alpine
    env_file: .env
    restart: always
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    networks:
      - linkwarden-network
  linkwarden:
    env_file: .env
    environment:
      - DATABASE_URL=postgresql://postgres:${POSTGRES_PASSWORD}@postgres:5432/postgres
    restart: always
    # build: . # uncomment to build from source
    image: ghcr.io/linkwarden/linkwarden:latest # comment to build from source
    ports:
      - 3000:3000
    volumes:
      - ./data:/data/data
    depends_on:
      - postgres
      - meilisearch
    networks:
      - linkwarden-network
  meilisearch:
    image: getmeili/meilisearch:v1.12.8
    restart: always
    env_file:
      - .env
    networks:
      - linkwarden-network
    volumes:
      - ./meili_data:/meili_data
  nginx-proxy-manager:
    image: jc21/nginx-proxy-manager:latest
    container_name: npm
    ports:
      - "81:81"    # Admin interface
      - "80:80"    # HTTP
      - "443:443"  # HTTPS
    volumes:
      - ./npm/data:/data
      - ./npm/letsencrypt:/etc/letsencrypt
    networks:
      - linkwarden-network
networks:
  linkwarden-network:
    driver: bridge
    enable_ipv6: true

This configuration will work with NPM front ending the https pieces, and will also work behind cloudflare. You’ll need to find the address of the container to put into the NPM proxy manager. This can be found with the following command:

sudo docker inspect <container ID> | grep IP

The output should look similar to

buraglio@dockhost1:/opt/linkwarden$ sudo docker inspect af8e7a6c4edd | grep IP
                "RSS_SUBSCRIPTION_LIMIT_PER_USER=",
                "PIPEDRIVE_CUSTOM_NAME=",
                "NEXT_PUBLIC_PIPEDRIVE_ENABLED=",
                "PIPEDRIVE_CLIENT_ID=",
                "PIPEDRIVE_CLIENT_SECRET=",
                    "IPAMConfig": null,
                    "IPAddress": "172.19.0.4",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "fd64:b2a0:6eac:1::1",
                    "GlobalIPv6Address": "fd64:b2a0:6eac:1::4",
                    "GlobalIPv6PrefixLen": 64,

for anyone who would rather not deal with this amount of complexity, linkwarden has a very reasonable hosted option .

IPB 195 - Start Network Automation with IPv6!

Thu, 05 Mar 2026 00:00:00 +0000

The hosts propose using IPv6 as a low-risk environment for learning network automation. Since production traffic typically runs on IPv4, experimenting with automated configurations on IPv6 allows engineers to get a two-for-one experience learning both IPv6 and automation with low risk of disruption.

Have a listen:

Podcast link: IPB195: Start Network Automation with IPv6!

Show links:

Netmiko Library

FREE course – Learning Python: Python for Network Engineers

IPB 194 - Navel Gazing at NAT in IPv6

Thu, 19 Feb 2026 00:00:00 +0000

Ed, Nick, and Tom discuss the need for Network Address Translation v6 to v6 (NAT66). While Network Prefix Translation (NPTv6) exists, its limitations make it insufficient for real-world business needs. They also highlight that without a standardized NAT66, the market is forcing vendors to implement their own, hindering widespread IPv6 adoption.

Have a listen:

Podcast link: IPB194: Navel Gazing at NAT in IPv6

Show links:

IPv6-to-IPv6 Network Address Translation (NAT66)

RFC 6296: IPv6-to-IPv6 Network Prefix Translation

Mikrotik wireguard optimization

Tue, 17 Feb 2026 00:00:00 +0000

Most modern mikrotik can handle reasonable wireguard performance, but it is a CPU based encryption model, so there are some tweaks that can be made to improve performance. The following can be used to optimize for better wireguard behavior. However, it should be noted that unlike the IPSec capabilities that are measured and reported on the Mikrotik product pages for each platform, wireguard limits are not published for any mikrotik platform. This can be translated into “you get what you get”, essentially, and as stated, wireguard is all CPU based, so perfornmance and scale will be limited by CPU.

Set the queuing for the WAN interface to `fq-codel` or `cake`

FQ-CoDel and CAKE are both modern queue management systems designed to reduce bufferbloat and ensure fair bandwidth distribution, but CAKE offers several enhancements:

1. Flow Hashing

FQ-CoDel: Uses a basic hash to assign packets to flows, which can lead to collisions under high flow counts.
CAKE: Uses an 8-way set-associative hash, drastically reducing collisions and improving flow isolation.

2. Fairness

FQ-CoDel: Fairness is per-flow—clients with more connections get more bandwidth.
CAKE: Adds per-host fairness (via Cobalt), so a client with 10 connections doesn’t dominate one with 1.

3. Shaping & Overhead Handling

FQ-CoDel: Often paired with a separate shaper (e.g., HTB), increasing CPU use.
CAKE: Includes an integrated shaper, is more CPU-efficient, and supports framing compensation (e.g., for PPPoE, ATM).

4. MSS & MTU Awareness

CAKE: Tracks packet sizes in bytes, not packets, avoiding issues with large GSO/GRO packets.
FQ-CoDel: Uses packet count, which can misrepresent memory usage.

5. Diffserv Support

CAKE: Built-in DiffServ mode for traffic class prioritization.
FQ-CoDel: No native Diffserv support.

/queue type
add kind=cake name=cake
/queue interface
set sfp-sfpplus1 queue=cake

Or, with fq_codel

/queue type
add kind=fq-codel name=fq-codel
/queue interface
set sfp-sfpplus1 queue=fq-codel

Disable fasttrack for the wireguard interface

/ip firewall raw add action=notrack chain=prerouting in-interface=wg1

Set the correct MTU and MSS in order to to account for encapsulation overhead. Clamp MSS on TCP traffic to prevent fragmentation.

/ip firewall mangle add protocol=tcp tcp-flags=syn action=change-mss new-mss=1400 chain=forward out-interface=wg1

The MTU and MSS are related but distinct values:

MTU (Maximum Transmission Unit) = 1420 bytes: This is the largest IP packet size the WireGuard interface can transmit, including all headers.
MSS (Maximum Segment Size) = 1400 bytes: This is the largest payload size for TCP data within that packet, excluding the TCP and IP headers.

The difference accounts for the 40-byte overhead of the TCP and IPv4 headers (20 bytes each). Explicitly:

MSS = MTU - 40
1400 = 1420 - 40

Setting MSS to 1400 ensures that when TCP adds its 40-byte header, the total packet size (1440 bytes) stays safely below the effective path MTU, preventing fragmentation. However, since WireGuard itself adds ~80 bytes of encapsulation overhead, the outer packet must be smaller — therefor setting the WireGuard interface MTU to 1420.

This combination avoids fragmentation and packet drops, especially on paths with lower MTU or blocked ICMP (which breaks Path MTU Discovery).

Posts on ForwardingPlane.net

piccolo-perf - a perfSONAR-lite for routers and SBCs

Where this actually fits

IPB 204 - Tayga and IPv6 Translation

IPv6 - Why You Should Care

IPB 203 - The Death of NAT

IPB 202 - How to Get Hands-On IPv6 Deployment Experience

IPB 201 - The Never-Ending Prefix Debate: Revisiting Best Current Practices

IPB 200 - Yes, IPv6 Is Complicated. IPv8 Won't Help

IPB 199 - Developing IPv6-Friendly Code

IPB 198 - IPv6 Privacy and Temporary Addresses

IPB 197 - SLAAC and the End of DHCP?

IPB 196 - Is End-to-End Connectivity the Right Goal?

Linkwarden with docker compose and nginx proxy manager

IPB 195 - Start Network Automation with IPv6!

IPB 194 - Navel Gazing at NAT in IPv6

Mikrotik wireguard optimization

Set the queuing for the WAN interface to fq-codel or cake

Disable fasttrack for the wireguard interface

Set the queuing for the WAN interface to `fq-codel` or `cake`