Why ranet3
Standard protocols
Peers only need standard IKEv2, ESP, Babel and SRv6.
Interoperability is checked against:
- strongSwan
- IKEv2 and ESP sessions with Ed25519 keys
- BIRD
- Babel routes with RTT metrics, matched route for route
- Linux
- Kernel seg6local acts on the SRv6 headers ranet3 writes
Any other router or switch that supports IKEv2 with Ed25519 keys, Babel and SRv6 should interoperate as well.
Common mesh VPN and SD-WAN tools (Tailscale, NetBird, ZeroTier, Nebula, etc.) admit only nodes that run their own agent, and ranet3 runs beside them on the same host.
Latency routing
Babel measures the round trip of every link and routes through a relay whenever the direct link is slower.
RTT is measured continuously, and packet loss and outages count against a link. Traffic always takes the fastest path, moving back to the direct link once it is faster again.
Segment routing
A policy on source and destination prefix sends traffic through chosen waypoints and out at a chosen exit. Segment routing is implemented in userspace and works even on macOS, whose XNU kernel has no support for it.
Waypoints can come in any order the user specifies and may repeat, e.g. A->B->C->B->D with D as the exit.
Benchmarks
95%
of the 10 GbE payload limit, 1 stream one way
8.39 of 8.84 Gbit/s
1.6-2.1x
kernel WireGuard throughput
All 6 tests
1.2-1.5x
wireguard-go throughput
All 6 tests
1.91-4.96 ms
RTT p99 under saturation
Kernel dataplanes 0.85-2.51 ms
Medians of 3 runs under saturation
Head to head
Each range is ranet3's result divided by the other dataplane's across the 6 tests below.
Kernel and userspace
Userspace dataplanes copy every packet into their own process and are usually expected to be slower than kernel ones.
* Plain TCP without tunnel
Kernel WireGuard stays at 5.1 to 5.4 Gbit/s one way.
Kernel IPsec stays at 4.0 to 4.7 Gbit/s because its single flow lands on 1 NIC receive queue.
Full results
In the "both" rows kernel IPsec carried only 4.67 and 4.14 of the 6 Gbit/s offered.