ranet3 is een SD-WAN-oplossing die gebruikmaakt van standaardprotocollen zoals IKEv2, ESP, Babel en SRv6 voor een interoperabele mesh-netwerkconfiguratie.
Kernfuncties
- Routing op basis van latentie: Via het Babel-protocol wordt de Round Trip Time (RTT) continu gemeten, waardoor verkeer automatisch via het snelste pad wordt geleid.
- Segment Routing (SRv6): Maakt het mogelijk om verkeer via specifieke waypoints naar een exit te sturen, wat ook op macOS werkt omdat het in userspace is geïmplementeerd.
- Interoperabiliteit: Het is compatibel met tools zoals strongSwan en BIRD.
Performance
Uit uitgebreide benchmarks blijkt dat ranet3 superieur is aan andere userspace-implementaties zoals wireguard-go. In tests op 10 GbE hardware behaalde ranet3 een doorvoer van 8.39 Gbit/s (één richting), wat neerkomt op 95% van de lijnlimiet. Hoewel kernel-implementaties van WireGuard en IPsec in sommige gevallen sneller zijn of lagere latentie hebben, omzeilt ranet3 bepaalde kernel-beperkingen (zoals receive queue bottlenecks bij IPsec), wat resulteert in een hogere totale doorvoer in specifieke scenario's.
ranet3: High performance policy routed IPsec mesh SD-WAN
Technische Specificaties
- Transport: Userspace ESP (RFC 4303) in tunnelmodus over UDP (RFC 3948)
- Handshake: IKEv2 (RFC 7296) met hybride ML-KEM (FIPS 203) sleuteluitwisseling (RFC 9370)
- Routing: Embedded Babel speaker (RFC 8966) met RTT-metrieken (RFC 9616) en bron-specifieke routes (RFC 9079)
- Steering: SRv6 (RFC 8986) op basis van bron/bestemmingsprefix
- Broncode: github:ranet3/ranet3
- Licentie: FSL-1.1-ALv2 / Apache-2.0
- Contact: mesh@ranet3.com
- Netwerken: Powering AS10779 / AS18932
Waarom ranet3?
Protocollen en routing
Standaard protocollen
- strongSwan: IKEv2 en ESP-sessies met Ed25519-sleutels.
- BIRD: Babel-routes met RTT-metrieken en overeenkomstige routes voor route-verificatie.
- Linux Kernel:
seg6local werkt op de SRv6-headers die ranet3 schrijft.
Elke andere router of switch die IKEv2 met Ed25519-sleutels, Babel en SRv6 ondersteunt, zou even tevoren interoperabel moeten zijn. In tegenstelling tot veel gangbare mesh VPN- en SD-WAN-tools (zoals Tailscale, NetBird, ZeroTier, Nebula, etc.), die alleen nodes accepteren die hun eigen agent draaien, kan ranet3 naast deze tools op dezelfde host draaien.
Routing op basis van latentie
Babel meet de round trip time (RTT) van elke verbinding en routeert via een relay zodra de directe verbinding trager is.
Voorbeeld:
- Pad A → B: 40 ms
- Pad B → C: 40 ms
- Direct Pad A → C: 265 ms
- Gekozen pad: Via B (totaal 80 ms) in plaats van de directe link (265 ms).
De RTT wordt continu gemeten; pakketverlies en uitval tellen mee in de weging van een verbinding. Verkeer kiest altijd het snelste pad en keert terug naar de directe verbinding zodra deze weer sneller is.
Segment routing
Een policy op basis van bron- en bestemmingsprefix stuurt verkeer via gekozen waypoints naar een gekozen exit. Segment routing is geïmplementeerd in userspace en werkt daarom zelfs op macOS, waarvan de XNU-kernel geen ondersteuning heeft voor deze functionaliteit.
Voorbeeld van route: Waypoint (DT46) → Laptop → Internet (Default route) → Exit
Waypoints kunnen in elke door de gebruiker opgegeven volgorde worden geplaatst en mogen herhaald worden (bijv. A → B → C → B → D, met D als exit).
Benchmarks
Gemeten op: 15 oktober 2026
Dataplane vergelijking
| Dataplane | Protocol en cipher | Performance (10 GbE payload limit, 1 stream één richting) | Doorvoer t.o.v. anderen | Latentie (RTT p99 onder verzadiging) |
|---|
| ranet3 (Userspace) | ESP in UDP, AES-256-GCM | 8.39 van 8.84 Gbit/s | 1.2-1.5x vs wireguard-go | 1.91-4.96 ms |
| wireguard-go (Userspace) | WireGuard, ChaCha20-Poly1305 | - | - | - |
| WireGuard (Kernel) | WireGuard, ChaCha20-Poly1305 | - | 1.6-2.1x sneller dan ranet3 | 0.85-2.51 ms |
| IPsec (Kernel xfrm) | ESP in UDP, AES-256-GCM | - | 1.8-3.9x sneller dan ranet3 | 0.85-2.51 ms |
Head-to-head analyse
De onderstaande tabel toont de resultaten van ranet3 gedeeld door de resultaten van de andere dataplane (waarbij een hogere waarde voor doorvoer beter is en een lagere waarde voor CPU/latentie).
| Dataplane | Doorvoer (hoger is beter) | CPU per Gbit/s (lager is beter) | Latentie p99 (lager is beter) |
|---|
| wireguard-go (user) | 1.2-1.5x beter | 0.8-0.9x beter | 0.2-1.0x gemengd |
| WireGuard (kernel) | 1.6-2.1x beter | 0.6x beter | 1.9-2.4x slechter |
| IPsec (kernel) | 1.8-3.9x beter | 1.1-1.7x slechter | 1.6-2.0x slechter |
Kernel versus Userspace
Userspace dataplanes kopiëren elk pakket naar hun eigen proces en worden daarom doorgaans als trager beschouwd dan kernel-implementaties.
Doorvoer (1 stream, Gbit/s):
| Implementatie | Eén richting | Beide richtingen | Aandeel van de lijn (één richting) |
|---|
| Lijnlimiet (10 GbE, plain TCP) | 8.84 | 18.76 | 100% |
| Kernel (beste van 2) | 5.35 | 7.46 | 61% |
| Userspace (wireguard-go) | 6.77 | 10.78 | 77% |
| Userspace (ranet3) | 8.39 | 14.87 | 95% |
- Kernel WireGuard blijft steken op 5.1 tot 5.4 Gbit/s (één richting).
- Kernel IPsec blijft steken op 4.0 tot 4.7 Gbit/s omdat een enkele flow op één NIC-ontvangstwachtrij (receive queue) landt.
Volledige resultaten
Doorvoer (Verzadigd, Gbit/s ontvangen)
Hoger is beter
| Testscenario | ranet3 (user) | wireguard-go (user) | WireGuard (kernel) | IPsec (kernel) |
|---|
| 1 stream, uit | 8.39 | 6.77 | 5.35 | 4.67 |
| 1 stream, in | 8.37 | 6.95 | 5.10 | 4.44 |
| 1 stream, beide | 14.87 | 10.78 | 7.46 | 4.67 |
| 8 streams, uit | 8.52 | 6.06 | 5.14 | 3.97 |
| 8 streams, in | 8.48 | 6.72 | 5.12 | 4.06 |
| 8 streams, beide | 15.79 | 10.33 | 7.41 | 4.10 |
CPU-kosten bij 3 Gbit/s aanbod
Bezetting cores per Gbit/s, beide hosts. Lager is beter
| Testscenario | ranet3 (user) | wireguard-go (user) | WireGuard (kernel) | IPsec (kernel) |
|---|
| 1 stream, uit | 0.909 | 1.079 | 1.51 | 0.672 |
| 1 stream, in | 0.925 | 1.092 | 1.525 | 0.664 |
| 1 stream, beide | 0.898 | 0.996 | 1.504 | 0.525 |
| 8 streams, uit | 0.996 | 1.213 | 1.740 | 0.845 |
| 8 streams, in | 0.990 | 1.182 | 1.748 | 0.866 |
| 8 streams, beide | 0.948 | 1.087 | 1.500 | 0.620 |
Opmerking: In de "beide" rijen transporteerde kernel IPsec slechts 4.67 en 4.14 van de aangeboden 6 Gbit/s.
Latentie onder verzadiging
RTT p99, ms. Lager is beter
| Testscenario | ranet3 (user) | wireguard-go (user) | WireGuard (kernel) | IPsec (kernel) |
|---|
| 1 stream, uit | 2.01 | 2.10 | 1.07 | 1.04 |
| 1 stream, in | 1.91 | 2.18 | 0.85 | 1.23 |
| 1 stream, beide | 3.17 | 3.15 | 1.65 | 1.76 |
| 8 streams, uit | 2.77 | 16.40 | 1.26 | 1.53 |
| 8 streams, in | 2.86 | 5.09 | 1.17 | 1.50 |
| 8 streams, beide | 4.96 | 7.69 | 2.48 | 2.51 |
Setup
Hardware
- Hosts: 2 x Dell PowerEdge C6420
- Processor: Intel Xeon Gold 6130 (16 cores, 32 threads)
- Geheugen: 192 GiB
- NIC: Intel X710
- Connector: SFP+
- Bandbreedte: 10 Gbit/s per richting
- Switch: Beide hosts op dezelfde Dell S5296F-ON
Software
- OS: Debian 13
- Kernel: Linux 6.12.111
- wireguard-go: 0.0.20250522
- wireguard-tools: 1.0.20260223
- iproute2: 7.1.0
- iperf3: 3.21
Methode
- Verkeer: TCP met cubic bij inner MTU 1400
- Streams: 1 en 8
- Belasting: Verzadigd voor doorvoer en latentie; 3 Gbit/s per richting voor CPU-kosten
- Richting: Eén richting (per kant) en beide richtingen gelijktijdig
- Runs: Mediaan van 3 runs van 10 seconden, met de dataplanes afgewisseld
- CPU-kosten: Bezetting cores vanuit
/proc/stat, opgeteld over beide hosts, met elke dataplane ongepinned
- Lijnlimiet: 8.84 Gbit/s TCP payload één richting (na ESP in UDP framing) en 18.76 Gbit/s beide richtingen zonder tunnel.
ranet3: High performance policy routed IPsec mesh SD-WAN
Technische Specificaties
- Transport: Userspace ESP (RFC 4303) in tunnelmodus over UDP (RFC 3948)
- Handshake: IKEv2 (RFC 7296) met hybride ML-KEM (FIPS 203) sleuteluitwisseling (RFC 9370)
- Routing: Embedded Babel speaker (RFC 8966) met RTT-metrieken (RFC 9616) en bron-specifieke routes (RFC 9079)
- Steering: SRv6 (RFC 8986) op basis van bron/bestemmingsprefix
- Broncode: github:ranet3/ranet3
- Licentie: FSL-1.1-ALv2 / Apache-2.0
- Contact: mesh@ranet3.com
- Netwerken: Powering AS10779 / AS18932
Waarom ranet3?
Protocollen en routing
Standaard protocollen
- strongSwan: IKEv2 en ESP-sessies met Ed25519-sleutels.
- BIRD: Babel-routes met RTT-metrieken en overeenkomstige routes voor route-verificatie.
- Linux Kernel:
seg6local werkt op de SRv6-headers die ranet3 schrijft.
Elke andere router of switch die IKEv2 met Ed25519-sleutels, Babel en SRv6 ondersteunt, zou even tevoren interoperabel moeten zijn. In tegenstelling tot veel gangbare mesh VPN- en SD-WAN-tools (zoals Tailscale, NetBird, ZeroTier, Nebula, etc.), die alleen nodes accepteren die hun eigen agent draaien, kan ranet3 naast deze tools op dezelfde host draaien.
Routing op basis van latentie
Babel meet de round trip time (RTT) van elke verbinding en routeert via een relay zodra de directe verbinding trager is.
Voorbeeld:
- Pad A → B: 40 ms
- Pad B → C: 40 ms
- Direct Pad A → C: 265 ms
- Gekozen pad: Via B (totaal 80 ms) in plaats van de directe link (265 ms).
De RTT wordt continu gemeten; pakketverlies en uitval tellen mee in de weging van een verbinding. Verkeer kiest altijd het snelste pad en keert terug naar de directe verbinding zodra deze weer sneller is.
Segment routing
Een policy op basis van bron- en bestemmingsprefix stuurt verkeer via gekozen waypoints naar een gekozen exit. Segment routing is geïmplementeerd in userspace en werkt daarom zelfs op macOS, waarvan de XNU-kernel geen ondersteuning heeft voor deze functionaliteit.
Voorbeeld van route: Waypoint (DT46) → Laptop → Internet (Default route) → Exit
Waypoints kunnen in elke door de gebruiker opgegeven volgorde worden geplaatst en mogen herhaald worden (bijv. A → B → C → B → D, met D als exit).
Benchmarks
Gemeten op: 15 oktober 2026
Dataplane vergelijking
| Dataplane | Protocol en cipher | Performance (10 GbE payload limit, 1 stream één richting) | Doorvoer t.o.v. anderen | Latentie (RTT p99 onder verzadiging) |
|---|
| ranet3 (Userspace) | ESP in UDP, AES-256-GCM | 8.39 van 8.84 Gbit/s | 1.2-1.5x vs wireguard-go | 1.91-4.96 ms |
| wireguard-go (Userspace) | WireGuard, ChaCha20-Poly1305 | - | - | - |
| WireGuard (Kernel) | WireGuard, ChaCha20-Poly1305 | - | 1.6-2.1x sneller dan ranet3 | 0.85-2.51 ms |
| IPsec (Kernel xfrm) | ESP in UDP, AES-256-GCM | - | 1.8-3.9x sneller dan ranet3 | 0.85-2.51 ms |
Head-to-head analyse
De onderstaande tabel toont de resultaten van ranet3 gedeeld door de resultaten van de andere dataplane (waarbij een hogere waarde voor doorvoer beter is en een lagere waarde voor CPU/latentie).
| Dataplane | Doorvoer (hoger is beter) | CPU per Gbit/s (lager is beter) | Latentie p99 (lager is beter) |
|---|
| wireguard-go (user) | 1.2-1.5x beter | 0.8-0.9x beter | 0.2-1.0x gemengd |
| WireGuard (kernel) | 1.6-2.1x beter | 0.6x beter | 1.9-2.4x slechter |
| IPsec (kernel) | 1.8-3.9x beter | 1.1-1.7x slechter | 1.6-2.0x slechter |
Kernel versus Userspace
Userspace dataplanes kopiëren elk pakket naar hun eigen proces en worden daarom doorgaans als trager beschouwd dan kernel-implementaties.
Doorvoer (1 stream, Gbit/s):
| Implementatie | Eén richting | Beide richtingen | Aandeel van de lijn (één richting) |
|---|
| Lijnlimiet (10 GbE, plain TCP) | 8.84 | 18.76 | 100% |
| Kernel (beste van 2) | 5.35 | 7.46 | 61% |
| Userspace (wireguard-go) | 6.77 | 10.78 | 77% |
| Userspace (ranet3) | 8.39 | 14.87 | 95% |
- Kernel WireGuard blijft steken op 5.1 tot 5.4 Gbit/s (één richting).
- Kernel IPsec blijft steken op 4.0 tot 4.7 Gbit/s omdat een enkele flow op één NIC-ontvangstwachtrij (receive queue) landt.
Volledige resultaten
Doorvoer (Verzadigd, Gbit/s ontvangen)
Hoger is beter
| Testscenario | ranet3 (user) | wireguard-go (user) | WireGuard (kernel) | IPsec (kernel) |
|---|
| 1 stream, uit | 8.39 | 6.77 | 5.35 | 4.67 |
| 1 stream, in | 8.37 | 6.95 | 5.10 | 4.44 |
| 1 stream, beide | 14.87 | 10.78 | 7.46 | 4.67 |
| 8 streams, uit | 8.52 | 6.06 | 5.14 | 3.97 |
| 8 streams, in | 8.48 | 6.72 | 5.12 | 4.06 |
| 8 streams, beide | 15.79 | 10.33 | 7.41 | 4.10 |
CPU-kosten bij 3 Gbit/s aanbod
Bezetting cores per Gbit/s, beide hosts. Lager is beter
| Testscenario | ranet3 (user) | wireguard-go (user) | WireGuard (kernel) | IPsec (kernel) |
|---|
| 1 stream, uit | 0.909 | 1.079 | 1.51 | 0.672 |
| 1 stream, in | 0.925 | 1.092 | 1.525 | 0.664 |
| 1 stream, beide | 0.898 | 0.996 | 1.504 | 0.525 |
| 8 streams, uit | 0.996 | 1.213 | 1.740 | 0.845 |
| 8 streams, in | 0.990 | 1.182 | 1.748 | 0.866 |
| 8 streams, beide | 0.948 | 1.087 | 1.500 | 0.620 |
Opmerking: In de "beide" rijen transporteerde kernel IPsec slechts 4.67 en 4.14 van de aangeboden 6 Gbit/s.
Latentie onder verzadiging
RTT p99, ms. Lager is beter
| Testscenario | ranet3 (user) | wireguard-go (user) | WireGuard (kernel) | IPsec (kernel) |
|---|
| 1 stream, uit | 2.01 | 2.10 | 1.07 | 1.04 |
| 1 stream, in | 1.91 | 2.18 | 0.85 | 1.23 |
| 1 stream, beide | 3.17 | 3.15 | 1.65 | 1.76 |
| 8 streams, uit | 2.77 | 16.40 | 1.26 | 1.53 |
| 8 streams, in | 2.86 | 5.09 | 1.17 | 1.50 |
| 8 streams, beide | 4.96 | 7.69 | 2.48 | 2.51 |
Setup
Hardware
- Hosts: 2 x Dell PowerEdge C6420
- Processor: Intel Xeon Gold 6130 (16 cores, 32 threads)
- Geheugen: 192 GiB
- NIC: Intel X710
- Connector: SFP+
- Bandbreedte: 10 Gbit/s per richting
- Switch: Beide hosts op dezelfde Dell S5296F-ON
Software
- OS: Debian 13
- Kernel: Linux 6.12.111
- wireguard-go: 0.0.20250522
- wireguard-tools: 1.0.20260223
- iproute2: 7.1.0
- iperf3: 3.21
Methode
- Verkeer: TCP met cubic bij inner MTU 1400
- Streams: 1 en 8
- Belasting: Verzadigd voor doorvoer en latentie; 3 Gbit/s per richting voor CPU-kosten
- Richting: Eén richting (per kant) en beide richtingen gelijktijdig
- Runs: Mediaan van 3 runs van 10 seconden, met de dataplanes afgewisseld
- CPU-kosten: Bezetting cores vanuit
/proc/stat, opgeteld over beide hosts, met elke dataplane ongepinned
- Lijnlimiet: 8.84 Gbit/s TCP payload één richting (na ESP in UDP framing) en 18.76 Gbit/s beide richtingen zonder tunnel.
Groetjes,