ranet3

..::----::.. .:-++++++++++++++-:. :=+++-:.. ..:-+++=: :=++-. .-+-. .=++-. :::::: . .::. :++=. :+#@@@@@@@@#+: *@@@@= :++= -#@@%*+-::-+*%@@#- :@@@@@@ .++= .*@@#- -#@@*. .#@@@@* -++. .#@@= =@@#. -++: .++- *@@- :++: -@@* :++. .@@# -%@@@@%- #@@. .--: -++ .++: %@@@@@@% +@@: ++- -++ %@@@@@@% +@@: ++- :++. .=+-. -%@@@@%- #@@. .++: .++- :%@@@%: :++: -@@* -++. -++. =@@@@@= =@@#. .++- .++= +%@%+ -#@@*. =++. :++= =*+-::-+*%@@#- =++: :++=. .#@@@@@@@@#+: .=++: .=++-. :::::: .-++=. :=++-. .-++=: :=+++-:.. ..:-+++=: .:-++++++++++++++-:. ..::----::.. High performance policy routed IPsec mesh SD-WANWhy ranet3Protocols and routingWhy ranet3Standard protocolsPeers only need standard IKEv2, ESP, Babel and SRv6.Interoperability is checked against:strongSwanIKEv2 and ESP sessions with Ed25519 keysBIRDBabel routes with RTT metrics, matched route for routeLinuxKernel seg6local acts on the SRv6 headers ranet3 writesAny 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 routingBabel measures the round trip of every link and routes through a relay whenever the direct link is slower.ABC40 ms40 ms265 msChosen path through B, 80 msDirect link, 265 msRTT 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 routingA 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.WaypointEndExitEnd.DT46LaptopInternetDefault routeWaypoints can come in any order the user specifies and may repeat, e.g. A->B->C->B->D with D as the exit.BenchmarksMeasured on 2026-10-15BenchmarksDataplaneRuns inProtocol and cipherranet3UserspaceESP in UDP, AES-256-GCMwireguard-goUserspaceWireGuard, ChaCha20-Poly1305WireGuardKernelWireGuard, ChaCha20-Poly1305IPsecKernel (xfrm)ESP in UDP, AES-256-GCM95%of the 10 GbE payload limit, 1 stream one way8.39 of 8.84 Gbit/s1.6-2.1xkernel WireGuard throughputAll 6 tests1.2-1.5xwireguard-go throughputAll 6 tests1.91-4.96 msRTT p99 under saturationKernel dataplanes 0.85-2.51 msMedians of 3 runs under saturationHead to headDataplaneThroughputhigher is betterCPU per Gbit/slower is betterLatency p99lower is betterwireguard-go user1.2-1.5x better0.8-0.9x better0.2-1.0x mixedWireGuard kernel1.6-2.1x better0.6x better1.9-2.4x worseIPsec kernel1.8-3.9x better1.1-1.7x worse1.6-2.0x worseEach range is ranet3's result divided by the other dataplane's across the 6 tests below.Kernel and userspaceUserspace dataplanes copy every packet into their own process and are usually expected to be slower than kernel ones.1 stream, Gbit/sOne wayBoth waysShare of lineone wayLine limit (10 GbE)8.8418.76*100%Kernel, best of 25.357.4661%Userspace, wireguard-go6.7710.7877%Userspace, ranet38.3914.8795%* Plain TCP without tunnelKernel 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 resultsThroughput, saturatedGbit/s receivedHigher is betterranet3userwireguard-gouserWireGuardkernelIPseckernel1 stream, out8.396.775.354.671 stream, in8.376.955.104.441 stream, both14.8710.787.464.678 streams, out8.526.065.143.978 streams, in8.486.725.124.068 streams, both15.7910.337.414.10CPU cost at 3 Gbit/s offeredBusy cores per Gbit/s, both hostsLower is betterranet3userwireguard-gouserWireGuardkernelIPseckernel1 stream, out0.9091.0791.5110.6721 stream, in0.9251.0921.5250.6641 stream, both0.8980.9961.5040.5258 streams, out0.9961.2131.7400.8458 streams, in0.9901.1821.7480.8668 streams, both0.9481.0871.5000.620In the "both" rows kernel IPsec carried only 4.67 and 4.14 of the 6 Gbit/s offered.Latency under saturationRTT p99, msLower is betterranet3userwireguard-gouserWireGuardkernelIPseckernel1 stream, out2.012.101.071.041 stream, in1.912.180.851.231 stream, both3.173.151.651.768 streams, out2.7716.401.261.538 streams, in2.865.091.171.508 streams, both4.967.692.482.51SetupHardware, software and methodSetupHardwareHosts2 x Dell PowerEdge C6420ProcessorIntel Xeon Gold 6130 with 16 cores and 32 threadsMemory192 GiBNICIntel X710ConnectorSFP+Bandwidth10 Gbit/s each waySwitchBoth hosts on the same Dell S5296F-ONSoftwareOSDebian 13KernelLinux 6.12.111wireguard-go0.0.20250522wireguard-tools1.0.20260223iproute27.1.0iperf33.21MethodTrafficTCP with cubic at inner MTU 1400Streams1 and 8LoadSaturated for throughput and latency and 3 Gbit/s each way for CPU costDirectionOne way in each direction and both ways at onceRunsMedian of 3 runs of 10 seconds with the dataplanes interleavedCPU costBusy cores from /proc/stat summed over both hosts with every dataplane unpinnedLine limit8.84 Gbit/s of TCP payload one way after ESP in UDP framing and 18.76 Gbit/s both ways without a tunnel