Skip to content

Add routing peer sizing guide#815

Draft
SunsetDrifter wants to merge 7 commits into
mainfrom
docs/routing-peer-sizing-guide
Draft

Add routing peer sizing guide#815
SunsetDrifter wants to merge 7 commits into
mainfrom
docs/routing-peer-sizing-guide

Conversation

@SunsetDrifter

Copy link
Copy Markdown
Contributor

Summary

Adds a new Sizing Routing Peers page under Manage → Networks (/manage/networks/sizing-routing-peers), giving admins a method to choose the size and number of routing peers from measured throughput.

What the page covers

  • A four-step sizing method — estimate peak throughput, read a per-peer capacity, compute how many active peers, then split load across Networks — threaded through one running example (Acme, 6,000 remote users).
  • The download/upload (encrypt/decrypt) distinction that actually drives sizing, since the encrypt path runs roughly twice as fast as decrypt.
  • A per-peer capacity reference table (1 → 64 vCPU) measured on AWS c6in.16xlarge (Intel Xeon Platinum 8375C), with the methodology and a small-packet caveat stated.
  • A userspace-mode table showing wireguard-go does not scale across cores, plus the cases where a routing peer ends up on userspace: missing/broken/conflicting kernel module, no TUN device (netstack, including rootless Docker), non-Linux peers, and forcing userspace to capture policy IDs and blocked traffic events.
  • Tuning levers (kernel WireGuard, matched interface, jumbo frames, cores up to the knee) and how to scale out across multiple Networks.
  • An honest high-availability model — failover (different metrics) vs. nearest-peer selection (equal metrics), and why neither balances a Network's load, so load is split deterministically by building more Networks.

Wiring

  • Adds the page to the docs navigation, under Networks.
  • Cross-links from How Routing Peers Work (a note in the HA section + a related tile) and the Networks overview.

Add a Sizing Routing Peers page under Networks covering the four-step
sizing method, a per-peer capacity table, the tuning levers that matter,
and how to scale out by sharding load across identical Networks.

Cross-link it from How Routing Peers Work (HA note + related tile) and
the Networks overview, and add it to the docs navigation.
Generalize the Acme example to remote users, correct the encrypt/decrypt
framing and reach the local network rather than the datacenter, use
'routing peer' instead of 'gateway', and rename the recap to Summary.
Correct the high-availability description: a single Network does not
balance load across its peers — different metrics give failover (one
peer carries all), equal metrics give latency-based nearest-peer
selection, which splits traffic by geography but never evenly. Shard
into more Networks to split load deterministically.

Also collapse redundant restatements, drop the secondary worked
example (the capacity table covers it), and slim the commodity-hardware
guidance.
Extend the capacity table down to 1 and 2 vCPUs, drop the 'or more' from
the interface column, and adjust the methodology note so the interface
column reads uniformly as the minimum NIC to pair with each size.
Add a userspace-mode capacity table showing wireguard-go does not scale
across cores (download plateaus ~6.8 Gbps, only ~4-5 cores used), and
the cases where a routing peer runs userspace: missing/broken/conflicting
kernel module, no TUN device (netstack, incl. rootless Docker), non-Linux
peers, and forcing userspace to capture policy IDs and blocked traffic
events. Name the exact benchmark CPU (Xeon Platinum 8375C).
Rename the Scaling out heading and reword the body, description, and
recap to talk about splitting load across more Networks instead of
sharding. Update the in-page anchor link to match the new heading.
Lead each direction bullet with Download:/Upload: and say the routing
peer encrypts/decrypts, tying the pulling/pushing distinction to the
capacity table's column names.
@coderabbitai

coderabbitai Bot commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d7247423-7256-4f6c-b346-22710435beb0

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch docs/routing-peer-sizing-guide

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

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.

1 participant