Airgapped · Infrastructure-agnostic · DDIL-real

Train on the internet you’ll fight on.

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 paths Time-varying SATCOM effects Real 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.

01 EMULATE THE INTERNET

Every hop degrades traffic its own way — because every hop has its own emulator.

GSP stands up real ISPs on real router software, then drops a dedicated WAN emulator into each inter-ISP link. Traffic is shaped hop by hop, the way it is on the internet.

  • Real control planes. VyOS routers run multi-area OSPF with area-0 cores, dual-homed provider ABRs, stub edge areas, and inter-ISP eBGP. Paths are selected and reconverged, not looked up.
  • One emulator per inter-ISP link. A terrestrial peering hop and a LEO SATCOM hop carry entirely independent delay, jitter, loss, correlation, and rate.
  • Real devices on emulated public space. Laptops, phones, servers, and whole enclaves get public identities and cross true customer, peer, and transit policy boundaries.
  • Impairment composes. Independent per-hop distributions produce the reordering, burst loss, and tail latency a single averaged pipe can never generate.
A single WAN emulator gives you one averaged pipe with one delay distribution and one hop of TTL. GSP composes impairment hop by hop across real routing — the most realistic emulated internet you can put inside an airgap.
Per-hop WAN emulation across three ISPs, compared with a single averaged emulator Customer devices reach ISP-A, a terrestrial peering emulator, ISP-B, a LEO SATCOM emulator, ISP-C, and remote services. Each ISP contains aggregation, provider-edge and core routers, and each emulator applies its own impairment. Below, a conventional single emulator collapses the whole WAN into one averaged link. GSP · A DEDICATED EMULATOR ON EVERY INTER-ISP HOP CUSTOMER laptop · phone server · enclave ISP-A agg pe core OSPF area 0 + edge eBGP to peers WANEMU L2 bump-in-wire PEERING · TERRESTRIAL 18 ms · 0.1% · 1 Gbps brisk · evenly spaced ISP-B agg prov core transit + peering dual-homed ABRs WANEMU leo-starlink LEO SATCOM 540–720 ms · 2% · handover slow · stalls · drops ISP-C core pe agg hosts the services public address space SERVICES mail web · DNS files real endpoints ONE PATH · TWO INTER-ISP HOPS · TWO INDEPENDENT IMPAIRMENT MODELS CONVENTIONAL · ONE EMULATOR AVERAGING THE WHOLE WAN devices (all of them) SINGLE WAN EMULATOR 558 ms · 2.1% loss (averaged) services (all of them) ✕ TTL shows one hop — traceroute cannot reproduce the path ✕ one lumped distribution — no per-hop bursts or reordering ✕ no per-ISP routing policy, no eBGP reconvergence ✕ one knob for every link — cannot degrade only the SATCOM hop REALISM IS NOT AN AVERAGE OF THE PATH — IT IS THE STRUCTURE OF THE PATH
PER-HOP EMULATION ACROSS REAL ROUTING vs. ONE AVERAGED PIPE
02 AUTOMATE IT

One profile change in a pipeline stage, and the same suite runs on a different internet.

GSP is API driven end to end and idempotent by construction. A gsp test stage owns the network its tests run under — it runs the suite clean, reshapes the link over REST, and runs the exact same suite again.

  • Before and after, same job. PUT /api/wanemu/{link}/profile swaps terrestrial-fiber for starlink-maritime between two identical test runs. The delta is the finding.
  • Reshape any link, live. PATCH /api/wanemu/{link}/impairment sets delay, jitter, loss, correlation, corruption, and rate per link and per direction on the running emulator. POST .../disable and /enable cut a hop and restore it mid-suite.
  • Real devices, driven from CI. POST /api/customers declares the endpoints; gspcli deploy customers converges them onto emulated public space and every router on the path carries their traffic.
  • Idempotent, so re-runs are free. Every layer reconciles toward config.yaml: unchanged config touches nothing, allocation is seeded, and the same input rebuilds a byte-identical environment.
Matrix your tests over network conditions the way you already matrix them over OS versions — unattended, reproducible, and inside the airgap.
A GitLab pipeline whose gsp test stage reshapes the emulated network between two identical test runs A GitLab CI/CD pipeline runs build, test, gsp test, package and deploy. The gsp test job activates a clean profile, runs the suite, activates a degraded maritime Starlink profile, and runs the same suite again. Two devices exchange traffic across every router in ISP-A and ISP-B through a WAN emulator. Before and after result cards compare latency, throughput, retransmits and test verdicts. GitLab CI/CD pipeline #4182 · airgapped runner passed BUILD TEST GSP TEST PACKAGE DEPLOY build 1m 04s unit 48s gsp test 2 runs · 1 profile swap package 3m 21s deploy 57s gsp test · script curl -XPUT $GSP/api/wanemu/isp-a-isp-b/profile -d '{"profile":"terrestrial-fiber"}' pytest tests/mission_sync.py --tag baseline ← BEFORE curl -XPUT $GSP/api/wanemu/isp-a-isp-b/profile -d '{"profile":"starlink-maritime"}' pytest tests/mission_sync.py --tag degraded ← AFTER same suite · same devices · same routers · one line changed applied to the running emulator · no redeploy, no restart THE PATH UNDER TEST · TWO DEVICES, EVERY ROUTER ON THE WIRE edge-laptop-01 175.148.93.14 ISP-A agg pe prov core BNG → edge area → ABR → area 0 every hop decrements TTL WANEMU PUT profile ↑ driven by the job ISP-B core prov pe agg area 0 → ABR → edge area → BNG eBGP peering at the cores mission-srv-02 89.69.91.10 TWO DEVICES ACTIVELY EXCHANGING TRAFFIC ACROSS EIGHT ROUTERS AND ONE EMULATOR SAME SUITE · SAME DEVICES · SAME ROUTERS · ONE PROFILE CHANGE BEFORE terrestrial-fiber clean long-haul reference AFTER starlink-maritime handover hiccups + motion fade p95 RTT 12 ms p95 RTT 612 ms throughput 940 Mbps throughput 118 Mbps retransmits 0.02 % retransmits 4.10 % 42 / 42 passed 38 / 42 — 4 timeouts sync retry < handover window
ONE PIPELINE STAGE, TWO IDENTICAL RUNS, TWO DIFFERENT INTERNETS
03 REHEARSE THE MISSION

Rehearse the operation on the network you will actually have — before it counts.

The same emulated internet becomes a mission-rehearsal range. Blue operators work from their real tooling across a degraded SATCOM reachback; the target sits behind real ISP hops on red-held infrastructure.

  • Rehearsal, not a tabletop. The operator drives the actual C2 console, over the actual tunnel, across links impaired to match the theater they deploy into.
  • The adversary has real distance. Reaching red infrastructure crosses genuine routing domains and policy boundaries, so hop count, TTL, and RTT signatures behave as they will on mission.
  • Replay the exact condition. Seeded impairment schedules make a failed rehearsal reproducible: change tradecraft, re-run the same network, compare honestly.
  • Train the failure, not the happy path. Handover gaps, rain fade, and emissions-control blackouts are scheduled events — operators learn where their tooling breaks in the lab.
Rehearsal finding: a 30-second fixed beacon straddles the 45-second LEO handover gap and the C2 session dies mid-operation. Re-run with a 12-second jittered beacon and resume tokens: the session re-establishes 8 seconds after the fade. That lesson cost nothing to learn here.
Blue operators rehearsing a cyber operation against a red IT system across degraded links A blue afloat mission cell reaches a red-held mail, file and directory server through a SATCOM emulator, ISP-A, a congestion emulator and ISP-B. A timeline below shows a fixed 30-second beacon failing across a 45-second LEO handover gap, and a jittered 12-second beacon with resume tokens recovering after it. MISSION REHEARSAL · BLUE OPERATOR vs. RED IT SYSTEM REHEARSED ACCESS + EXFIL ROUTE BLUE · AFLOAT CELL C2 console cyber operators real tooling · real tunnel WANEMU leo-starlink SATCOM REACHBACK handover gaps · fade ISP-A pe core eBGP peering WANEMU busy-hour TRANSIT CONGESTION ISP-B core pe transit to red RED · TARGET ENCLAVE red IT admins mail file share directory OBJECTIVE · ACCESS + EXFIL four emulated hops from the operator real TTL · real RTT signature WHAT THE REHEARSAL EXPOSES · C2 BEACON vs. LEO HANDOVER GAP HANDOVER GAP · 45 s RUN 1 · beacon 30 s, fixed ✕ C2 session dead — never returns RUN 2 · beacon 12 s + jitter ✓ resumed 8 s after the fade — operation continues SAME SEED · SAME NETWORK · CHANGE THE TRADECRAFT AND RE-RUN the rehearsal fails here, in the lab, where failing is free
ONE OPERATOR, FOUR EMULATED HOPS, A RED TARGET — AND A LESSON LEARNED EARLY
Why it is different

Nothing important is hand-waved.

GSP combines deployment, routing, customer ingress, dynamic WAN impairment, and observability into one product instead of asking the customer to assemble a range from unrelated tools.

operator@edge-kit — connected through GSP
$ 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=58 time=561 ms
64 bytes: icmp_seq=2 ttl=58 time=574 ms
Request timeout for icmp_seq 3 ← that is the point
64 bytes: icmp_seq=4 ttl=58 time=559 ms
L2 bump-in-the-wire impairmentRouters keep their real adjacency while the link between them degrades.
Dynamic profilesLEO handovers, rain fade, busy-hour congestion, sea-state swell, bursts, and outages evolve over time.
Real customer endpointsServers, laptops, radios, phones, enclaves, gateways, and remote operators exchange actual traffic.
One common operating pictureMonitor topology, inspect routers, control impairments, onboard customers, and open documentation from the UI.
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. That package crosses the boundary through the customer’s approved transfer process. Every runtime artifact, image, chart, binary, and dependency is already inside.

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.

Connected build zonegspcli package build
fetch · verify · hash · assemble
VERIFIED
GSP PACKAGE
Operational enclavegspcli deploy
RKE2 · ISPs · customers · WANEMU · UI
✓ the only supported deployment 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.

Two real GSP profiles plotted over time: leo-starlink latency spikes and rain-fade bandwidth collapse The leo-starlink profile holds 25 milliseconds of latency and adds a 40 millisecond handover spike every 15 seconds for 1.5 seconds. The rain-fade profile ramps bandwidth from 30 down to 6 megabits over a 30 second fade-in, dwells for 20 seconds, recovers over 20 seconds and stays clear for 20 seconds. DYNAMIC PROFILES ARE SCHEDULED, NOT RANDOM leo-starlink · latency base 25 ms · handover +40 ms every 15 s for 1.5 s 80 25 0 ms handover spikes 0 s 30 s 60 s 90 s rain-fade · bandwidth 30 → 6 Mbit/s · fade-in 30 s, dwell 20 s, recover 20 s, clear 20 s 30 6 Mbit fade-in dwell · loss 8% · corrupt 5% recover clear
REAL SHIPPED PROFILES · REPLAYED THE SAME WAY EVERY RUN
bandwidth tbf rate cap latency + jitter loss + correlation corruption bit errors queue limit buffer depth per direction a2b · b2a · both enable / disable hard cut

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 / 06
Full ecosystem

GSP Architecture

GSP creates an airgapped internet as a software-defined range, then lets real mission systems interact with it through controlled customer ingress. The internet behavior is abstracted from the infrastructure that hosts it.

Presenter cue
Start at the bottom with customer-owned infrastructure. Move upward through Kubernetes and the emulated internet, then finish with real operators and mission systems.
Emulated ISP fabric Satellite / long-haul Mission edge Customer ingress
Full Gray Space Parallel ecosystem A deployment device provisions three Kubernetes nodes. Customer devices and a routed enterprise network all enter the right-side gateway before reaching ISP destinations, including a standalone naval ISP reached through satellite communications. MISSION EDGE · ALL CUSTOMER PATHS ENTER THE GATEWAY BEFORE AN ISP Mission serverC2 · data · services Mobile operatorphone · tablet · radio Routed enterprise customerreal external router · enterprise LAN SERVERPHONEUSERS US Naval standalone ISP afloat servers · mission operatorsrouted naval enclave SATCOM / LEO THE GSP PARALLEL INTERNET real routing domains · public addressing · policy · packet hops · DNS · impairment ISP NORTH AMERICA ISP EUROPE ISP PACIFIC CUSTOMER-OWNED INFRASTRUCTURE · AIRGAPPED / DISCONNECTED / CLOUD / HYBRID YOU ARE HERE! Deployment devicegspcli · verified package tarballdeployment configuration RKE2 KUBERNETES CLUSTER Node VM 01 Node VM 02 Node VM 03 Gateway VM(s)customer ingress · routed CPEtunnels · ISP attachments SCP ALL CUSTOMER INGRESS GATEWAY → ISP ATTACHMENTSROUTED CUSTOMER → GATEWAY → NAVAL ISP
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.

Open embedded page ↗
Baked standalone corpus

GSP Documentation

The complete documentation set is embedded in this one file and rendered with the same sidebar/search pattern as the GSP UI Docs tab.