GSP stands up a complete parallel internet on your own hardware:
real ISP routing, mission-relevant SATCOM and degraded-link effects, and real devices
living on emulated public address space. Fully airgapped. Inside your wire.
Real routing, not mocked pathsTime-varying SATCOM effectsReal devices and mission traffic
0internet dependencies at deploy time. The verified package crosses the airgap once.
Realrouters, BGP paths, packet hops, addressing, traffic, and endpoint behavior.
Livelatency, jitter, loss, bandwidth, corruption, handovers, fades, and outages.
1declarative configuration and one management plane for the entire environment.
Why it exists
The tactical edge is DDIL. The lab usually isn’t.
Systems proven on perfect networks meet latency, handovers, rain fade, congestion, and loss for the first time in theater. GSP moves that discovery left—into a repeatable lab environment.
01 · FIDELITY
◎
A real parallel internet
Packets cross real routing domains and real policy boundaries. Traceroute, TTL, peering, customer transit, and failure behavior have the structure operators expect.
02 · REPEATABILITY
↻
Reproduce the hard failure
Declarative topology and seeded impairment schedules let teams replay the same contested network condition after a fix—not argue about an unrepeatable anomaly.
03 · SOVEREIGNTY
◇
Entirely inside your wire
No cloud control plane, license server, phone-home, or deploy-time pull. GSP brings the internet behavior you need without bringing the internet into the enclave.
How to use this
Emulate it. Automate it. Rehearse on it.
One emulated internet serves three jobs: it reproduces the network faithfully, it takes orders from a pipeline, and it becomes a range operators can rehearse a mission on.
01 · EMULATE
◎
Every hop degrades traffic its own way
VyOS routers run multi-area OSPF and inter-ISP eBGP, so paths are selected and reconverged rather than looked up. A dedicated WAN emulator sits on every inter-ISP link, giving a terrestrial peering hop and a LEO SATCOM hop entirely independent delay, jitter, loss and rate.
Independent per-hop distributions compose into the reordering, burst loss and tail latency that a single averaged pipe can never generate.
02 · AUTOMATE
⇄
Same suite, different internet
GSP is API driven end to end and idempotent by construction. A pipeline stage runs its suite clean, swaps terrestrial-fiber for starlink-maritime over REST, and runs the identical suite again. The delta is the finding.
Delay, loss, corruption and rate are settable per link and per direction on a running emulator, and a hop can be cut and restored mid-suite. Matrix tests over network conditions the way you already matrix them over OS versions.
03 · REHEARSE
◈
Rehearse on the network you will actually have
Operators drive their real C2 console over the real tunnel, across links impaired to match the theater they deploy into. Reaching the target crosses genuine routing domains, so hop count, TTL and RTT signatures behave as they will on mission.
Seeded schedules make a failed rehearsal reproducible — a 30-second fixed beacon dies across a 45-second LEO handover gap; a 12-second jittered beacon with resume tokens recovers 8 seconds after the fade. That lesson costs nothing to learn here.
Airgap-first by design
Airgap is not a deployment option. It is the only supported deployment model.
We develop and validate the product from day one as a disconnected system so continuous airgap operation remains a first-class requirement—not a late-stage packaging exercise.
Connected once. Airgapped for operation.
A connected build device assembles and verifies one package with gspcli package build — fetch, verify, hash, assemble. That package crosses the boundary through the customer’s approved transfer process, and gspcli deploy stands up RKE2, the ISPs, customers, WANEMU and the UI entirely inside the enclave. Every runtime artifact, image, chart, binary, and dependency is already there.
No deploy-time pulls. No license server. No cloud control plane. No phone-home path.
The disconnected path is exercised continuously in development because it is the product path.
Next: WAN emulation
Impairment is the product.
Routers make the path real. The emulators make the path hard. Every impaired link is a transparent Layer-2 bump-in-the-wire: the routers either side keep their real adjacency while the wire between them behaves like weather, orbit, congestion, or emissions control.
REAL SHIPPED PROFILES · REPLAYED THE SAME WAY EVERY RUN
bandwidth tbf rate caplatency + jitterloss + correlationcorruption bit errorsqueue limit buffer depthper direction a2b · b2a · bothenable / disable hard cut
operator@edge-kit — a real device on the emulated internet
$ gspcli connect afloat-02
✓ identity 175.148.93.101 (customer afloat-02)✓ tunnel up (emulated public routes installed)$ ping 89.69.91.10 # ship → SATCOM → emulated internet
64 bytes: icmp_seq=1 ttl=58time=561 ms
64 bytes: icmp_seq=2 ttl=58time=574 msRequest timeout for icmp_seq 3← that is the point
64 bytes: icmp_seq=4 ttl=58time=559 ms
Pulse — brief, repeating hits
A clean link that keeps getting punched on a schedule. handover, burst, outage: LEO beam switches, obstruction loss bursts, mast blockage, EMCON blackout windows, flapping backhaul.
Envelope — it comes on gradually
Ramp in, dwell at the worst of it, recover, run clear. fade, swell, congestion: rain storms, sea-state mispointing, diurnal busy hour, and buffer-filling congestion collapse.
Ladder — capacity steps down
Adaptive coding and modulation under fade. acm walks bandwidth down through real modcod tiers and holds a loss floor at the bottom rung, the way a satellite modem actually degrades.
Markov — good and bad regimes
Session-level burstiness instead of tidy averages. gilbert-elliott flips between a good state and a lossy bad state on mean dwell times, so retransmits clump the way they do on a real link.
Oscillator — continuous wobble
doppler walks delay up and down on a period, modelling range-rate change as a satellite or a ship moves. Layer it under any of the above — modulators stack in an ordered list.
21built-in profiles
9modulator types
∞your own, same schema
Terrestrial fiber and congestion · GEO, MEO and LEO satellite · WGS Ka maritime and MUOS narrowband · Starlink at sea · sea state · EMCON · LTE and 5G · congestion collapse. All shipped inside the airgap package, all controllable over REST.
01 / 05
Follow the deployment
Demo Architecture
Use this view as the live map of what exists now and what each deployment target adds.
Cometfall reflects local config · replace GCP TEST-NET placeholders before a cloud demo
deploy / package Kubernetes live customer traffic impaired link
drag node · drag background · wheel to zoom · click to inspect
Baked standalone reference
WAN Emulator Profiles & Effects
The complete interactive profile guide is embedded directly in this HTML—no server, repository, or network request required.
The complete documentation set is embedded in this one file and rendered with the same sidebar/search pattern as the GSP UI Docs tab.
WAN Emulator — Profiles & Effects, Explained
GSP · WAN Emulator · engineer & user reference
How the WAN emulator shapes traffic
Every impairment the emulator can apply, and every built-in profile, shown as
live traffic. Watch packets cross a link and get delayed, dropped, corrupted, reordered,
throttled, or buffered — then see the time-varying dynamics you can name in config, how the
built-in profiles combine them, and build your own. Start on Overview; jump to Build your
own when you want to author one.
How to read the animations. Each demo is one link: a sender (TX) on the
left, a receiver (RX) on the right, and the emulator in between. Little squares are packets. The
stack climbing at TX is the emulator's queue; watch it drain packet-by-packet into the sender as
the link serves it. A big bright ✕ marks a drop. Animations are
illustrative, not to scale — exact values are in the grey chips. Dynamic demos draw a
timeline of their schedule with a moving playhead.
This page teaches; the emulator decides. The simulations here are approximations —
in particular, when several dynamics overlap, the real scheduler merges them per field
(strongest departure from base wins), while this page picks one dominant envelope. Before using
any profile YAML for real, check it against the running emulator:
POST /api/v1/profiles/validate.
Profile focus
The deep reference for one profile at a time: what it models, how the schedule
behaves, exactly where you'd reach for it, what you can and can't tune today, how it differs from its
neighbours, the tweaks people actually make, and the modulators worth stacking with it in a custom
profile. Pick a profile — the Overview tab is the at-a-glance catalog; this is the manual.
What's configurable, across every profile. A profile is a static
base (all absolute values) plus an ordered list of dynamics. Base fields:
bandwidth latency jitter loss lossCorr corrupt corruptCorr duplicate reorder limit.
Pulse fields (handover/burst/outage) must be deltas (+/-) so overlapping
pulses add; envelope peak_* may be absolute or delta; an envelope takes either a
cycleor phase durations, not both; markov bad: values are absolute.
config.yaml
The emulator is authoritative — validate any edit before use:
POST /api/v1/profiles/validate. A per-link emulation: field overrides a
single parameter at deploy without touching the profile.
Build your own profile
Start from a built-in profile (or from scratch), then tune the static base
and stack on any of the nine dynamics — the link reacts live above. The right column shows the
two ways to ship what you built. Approach A — a named custom profile under the top-level
wanemu_profiles: key: reusable across links and it carries dynamics:.
Approach B — reference the nearest built-in profile and pin individual fields with a per-link
emulation: override under wanemu:: quick for a one-off, but static base fields only.
Approach A always works; approach B appears only when a static pin can faithfully reproduce your build (it is
withheld, with the reason, when it cannot).
base — static impairment
dynamics — time-varying modulators
config.yaml — approach A: a named custom profile
Define it once under the top-level wanemu_profiles: key (a sibling of
wanemu:, not nested inside it), then reference it by name from any impaired link's
profile:. The whole base + dynamics travel with the name, and it is reusable across links.
config.yaml — approach B: a built-in plus per-link overrides
A per-link emulation: block pins static base fields only. It cannot add,
remove, or edit dynamics:, and pinning a field a dynamic drives freezes that field flat. When
your build can't be expressed this way, approach B is withheld and only A is valid. (Verified against the
engine: emulation parses to an EmulationSpec applied as pins, last each tick.)
the emulator is authoritative — validate before use:
POST /api/v1/profiles/validate