Netzbremse Sidecar

Netzbremse Sidecar

Netzbremse is a campaign by AKVorrat/Epicenter.Works that measures peering bottlenecks at German ISPs. Their headless measurement tool runs automated speed tests through Cloudflare endpoints to detect artificial throttling at ISP peering points.

While DOCSight does not currently have a dedicated netzbremse module, running the netzbremse container alongside DOCSight gives you an additional data source for documenting peering issues -- complementing DOCSight's DOCSIS signal monitoring and Speedtest Tracker integration.

Note: Netzbremse currently focuses on Deutsche Telekom peering. Vodafone support has been requested but is not yet available.

What It Measures

Netzbremse tests download/upload speed, latency, jitter, and loaded latency through multiple Cloudflare endpoints. This specifically measures peering performance -- a different layer than what Speedtest Tracker or DOCSight's DOCSIS monitoring covers:

Tool	What it measures
DOCSight	Physical layer -- DOCSIS signal quality (power, SNR, errors)
Speedtest Tracker	General speed -- nearest Ookla server
Netzbremse	Peering performance -- Cloudflare endpoints across ISP boundaries
Connection Monitor	Latency/loss -- continuous ICMP/TCP probing

Setup

1. Add the container

Add the netzbremse container to your existing docker-compose.yml:

services:
  # ... your existing docsight service ...

  netzbremse:
    image: ghcr.io/akvorrat/netzbremse-measurement:latest
    container_name: netzbremse
    restart: unless-stopped
    environment:
      NB_SPEEDTEST_ACCEPT_POLICY: "true"
      NB_SPEEDTEST_INTERVAL: "21600"         # Every 6 hours (recommended)
      NB_SPEEDTEST_JSON_OUT_DIR: "./json-results"
    volumes:
      - ./netzbremse-results:/app/json-results
    deploy:
      resources:
        limits:
          memory: 1G
          cpus: "1"

2. Accept the privacy policy

You must read the privacy policy at netzbremse.de/speed and the Cloudflare terms before setting NB_SPEEDTEST_ACCEPT_POLICY: "true".

3. Start

docker compose up -d

View results:

docker compose logs -f netzbremse

Configuration

Variable	Default	Description
NB_SPEEDTEST_ACCEPT_POLICY	-	Required. Set to "true" after reading the privacy policy.
NB_SPEEDTEST_INTERVAL	3600 (1h)	Seconds between tests. See bandwidth note below.
NB_SPEEDTEST_TIMEOUT	3600	Max duration per test in seconds.
NB_SPEEDTEST_RETRY_INTERVAL	900 (15min)	Delay between retries after failures.
NB_SPEEDTEST_RETRY_COUNT	3	Max consecutive failures before exit.
NB_SPEEDTEST_JSON_OUT_DIR	-	Directory for JSON result files.
NB_SPEEDTEST_INTERVAL=0	-	Oneshot mode: run once and exit.

Bandwidth Considerations

Each netzbremse test run uses 500-800 MB of bandwidth (headless Chromium, multi-endpoint). At the default 1-hour interval, that is 12-19 GB/day.

Recommended intervals:

Interval	Daily traffic	Use case
1 hour (default)	~12-19 GB	Maximum data points, metered connections beware
6 hours (recommended)	~2-3 GB	Good balance for long-term peering trends
12 hours	~1-1.5 GB	Minimal footprint
24 hours	~0.5-0.8 GB	Daily snapshot only

If you also run Speedtest Tracker, keep total bandwidth in mind. Netzbremse measures peering trends over weeks/months -- frequent tests are less important than consistency.

Viewing Results

Netzbremse writes JSON result files to the configured output directory. You can view these with:

Community Dashboard

The netzbremse-dashboard by @lwndp provides a Streamlit-based visualization. Add to your compose setup:

  netzbremse-dashboard:
    image: ghcr.io/lwndp/netzbremse-dashboard:latest
    container_name: netzbremse-dashboard
    restart: unless-stopped
    environment:
      REFRESH_INTERVAL_SECONDS: 3600
    volumes:
      - ./netzbremse-results:/data:ro
    ports:
      - "8501:8501"
    deploy:
      resources:
        limits:
          memory: 256M
          cpus: "0.5"

Dashboard available at http://<your-host>:8501.

Raw JSON

Each result file contains:

{
  "sessionID": "...",
  "endpoint": "https://custom-t2.speed.cloudflare.com",
  "success": true,
  "result": {
    "download": 88206020,
    "upload": 11636039,
    "latency": 49.8,
    "jitter": 2.3,
    "downLoadedLatency": 62.5,
    "downLoadedJitter": 3.1,
    "upLoadedLatency": 45.2,
    "upLoadedJitter": 1.8
  }
}

Download/upload values are in bytes/second (divide by 1,000,000 for Mbps).

How This Helps with ISP Complaints

If your DOCSight DOCSIS signals look healthy but netzbremse shows speed degradation to Cloudflare, that is evidence of a peering problem -- not a last-mile issue. This distinction is critical for ISP complaints and BNetzA filings:

• DOCSIS signals OK + Speedtest OK + Netzbremse slow = Peering bottleneck
• DOCSIS signals OK + Speedtest slow + Netzbremse slow = General ISP congestion
• DOCSIS signals bad + everything slow = Last-mile problem (your connection)

Related

• Speedtest Tracker
• Connection Monitor
• BNetzA Breitbandmessung
• Filing a Complaint
• netzbremse-measurement on GitHub