Skip to content

testbed: add Docker router-based testbed#51

Draft
srene wants to merge 1 commit into
topdiscfrom
feat/docker-testbed-direct-ips
Draft

testbed: add Docker router-based testbed#51
srene wants to merge 1 commit into
topdiscfrom
feat/docker-testbed-direct-ips

Conversation

@srene

@srene srene commented May 3, 2026

Copy link
Copy Markdown
Member

Summary

Replaces the existing Docker testbed in PR #18 with a simpler design that drops NAT entirely. Each node container has its actual configured IP on a single Docker bridge — no router, no virtual public IPs, no NAT classes.

Design

Concern Implementation
Network topology single bridge (10.100.0.0/16)
Container IP real, set via docker run --ip
Per-node latency tc netem inside each container
Per-node bandwidth tc htb inside each container
Privileged setup docker run --cap-add=NET_ADMIN per container

IPs are laid out across distinct /24s (node N → 10.100.N.1), so the per-bucket IP-subnet cap (regBucketSubnet=24) is exercised meaningfully.

Files

  • testbed/docker/node/Dockerfile — Alpine + iproute2 + the devp2p binary built from project root.
  • testbed/docker/node/entrypoint.sh — applies tc htb + tc netem if NODE_BW_MBIT / NODE_LATENCY_MS env vars are set, then execs devp2p.
  • testbed/discv5-docker-config.json — example 100-node config with min/maxLatencyMs and min/maxBandwidthMbit ranges.
  • testbed/testbed/network.pyNetworkDocker rewritten; Network.prepare(params) hook added so subclasses see config params before start_node is called.
  • testbed/README.md — Docker-mode section added.

What this PR does NOT include

  • NAT simulation. If we ever need to test discv5 behaviour against NATted peers, that's a separate follow-up — not blocking real-network testing.
  • Pairwise realistic latencies. Per-node latency is sampled uniformly from [min, max] per run. A follow-up will integrate the MarcoPolo/ethereum-network-latencies dataset for true pairwise predicted RTTs (will likely live alongside a parallel simnet-based testbed).

Test plan

  • Build image: docker build -t discv5-testbed-node -f testbed/docker/node/Dockerfile .
  • Smoke run on Linux: testbed/run.py --docker --config testbed/discv5-docker-config.json --no-analysis --name docker-smoke
  • Verify nodes register and search across virtual IPs.
  • Confirm tc shaping: docker exec discv5-node-1 tc qdisc show dev eth0
  • Run analyse: testbed/analyse.py discv5_test_logs/docker-smoke/

Marking as draft until I've validated the smoke run on a Linux host.

The previous Docker mode used a per-node bridge network (one /24 per
node) which required N docker network create calls plus a host-level
iptables --flush of DOCKER-ISOLATION-STAGE-1. Setup time scaled with
node count, the iptables flush needed sudo, and the NAT machinery
served no purpose now that NAT-class simulation is out of scope.

Replace it with a single user-defined bridge (10.100.0.0/16) where each
node container gets its actual configured IP via 'docker run --ip'.
Nodes communicate directly through the bridge with no NAT and no router.
IPs are laid out so each node falls in a distinct /24 (node N ->
10.100.N.1), exercising regBucketSubnet=24 in the discv5 IP cap.

Per-node bandwidth and latency, when configured via min/max ranges in
the run config, are sampled and applied inside each container via
'tc htb' + 'tc netem' on eth0. Nothing is shared on the host.

Adds:
  testbed/docker/node/Dockerfile         build context = project root
  testbed/docker/node/entrypoint.sh      tc shaping + exec devp2p
  testbed/discv5-docker-config.json      example config with bw/latency
  testbed/README.md                      Docker-mode section
  Network.prepare(params)                hook so subclasses see params
                                         before start_node is called

Removes from NetworkDocker:
  per-node bridge creation
  iptables --flush hook in start_nodes
  config_network() docker exec tc rules
@srene srene changed the title testbed: simplify Docker mode to direct per-node IPs without NAT testbed: add Docker router-based testbed May 4, 2026
@srene srene self-assigned this May 4, 2026
@srene srene linked an issue May 4, 2026 that may be closed by this pull request
srene added a commit that referenced this pull request May 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Task 3.1.2: Add simnet-based in-process testbed

1 participant