3-Plane Classification — primer¶

Help Center primer for the bench's 3-plane administrative split. Pairs with ARCHITECTURE.md and the project_module_planes_classification_2026_05_10 memo.

What it is¶

The bench's 37 MÓDULOs are administratively split into 3 planes based on function. This split governs: - Where each MÓDULO can live (on-prem only vs cloud-portable) - Which MÓDULOs can run in air-gap vs need Internet - How the cloud-split future (CONTROL plane to SaaS) is staged

The 3 planes¶

DATA PLANE (22 MÓDULOs)¶

Carry actual test traffic. Always on-prem (cloud impossible — they handle the bench's data path).

ISP (1) — synthetic ISP / default route
SDWAN CoR-{1..10} (10) — IPSec tunnels
VXLAN-{1..3} (3) — VTEP front-ends
PW (1) — browser-engine agents
synthetic-load engine (1) — synthetic-load agents
GO (1) — MAC/ARP stress agent
IPr (1) — iperf endpoint
DoYour (1) ⭐ 2026-05-10
KALI (1) ⭐ 2026-05-10
TREX (1) ⭐⭐ 2026-05-10
HAR (1) ⭐⭐ 2026-05-10

CONTROL PLANE (5 MÓDULOs)¶

Carry control-plane signaling. Cloud-portable in the future cloud-split scenario (when SaaS-side orchestration is enabled).

BGP-{1..4} (4) — eBGP peers
OSPF (1) — OSPFv2/v3 LSA injection

MGMT PLANE (10 MÓDULOs)¶

Operate the bench. Split into MGMT-heavy (mandatory on-prem because of storage gravity) and MGMT-light (cloud-portable).

MGMT-heavy (storage gravity → MUST stay on-prem): - SYSLOG — receives log volume - FLOW — TSDB for flow telemetry - CLONER (cache + 9 functions) - Infra Stack (Postgres + Prometheus + Grafana)

MGMT-light (cloud-portable): - SNMP — outbound polls only - API INFRA — vendor REST orchestrator - CLI — SSH/TELNET orchestrator - CA — cert orchestrator (PKI) - VALIDATOR — central enrollment + ML cortex - RELAY ⭐⭐ 2026-05-10 — bridge OOBI ↔ customer MGMT - GATEWAY ⭐⭐ 2026-05-10 — operator entry proxy

PERSONAS controller is hybrid — controller logic in MGMT, persona pods in DATA.

Storage gravity principle¶

The principle that determines on-prem vs cloud:

Storage stays where data is born.

Telemetry that originates on the bench (SYSLOG records, FLOW records, PCAPs, CLONER cache) is too costly to ship across Internet. Mandatory on-prem.

Telemetry that's just passing through MGMT-light MÓDULOs (SNMP polls, SSH commands, vendor API calls) has small footprint and can route through cloud SaaS in the future cloud-split scenario.

Cloud-split future (DEFERRED, v6.0+)¶

The 3-plane classification was designed to enable a future: - DATA + MGMT-heavy stay on-prem (storage gravity) - CONTROL + MGMT-light go SaaS (cloud orchestration) - CLONER fn #8 (cloud proxy) is the L3 transport

Today's bench runs everything on-prem. The classification is the preparation for that future split.

Air-gap implications¶

Plane	Works in air-gap?
DATA	yes (always)
CONTROL	yes (assuming BGP/OSPF peers are local — typical bench)
MGMT-heavy	yes (storage on-prem)
MGMT-light	yes for most ops; CA + CLONER may need OBP for refreshes

Common questions¶

Why does "PERSONAS controller" sit between MGMT and DATA? The controller logic (UI / API / orchestration) is MGMT. The persona pods themselves serve test traffic (DATA). Splitting lets the controller cloud-port someday while persona pods stay on-prem.

Can RELAY.Art ever leave on-prem? No — RELAY needs L2 reach to customer MGMT NICs. Always on-prem regardless of cloud-split.

Why is HAR.Art DATA-plane if it replays at L7? Because it generates traffic against the DUT. Test-traffic-generating MÓDULOs are DATA-plane regardless of which OSI layer they operate at.

Why is the CLONER cache MGMT-heavy? The cache holds cloned website content (could be GBs per persona). Shipping that across Internet on every test would be prohibitive. Storage gravity wins.

ARCHITECTURE.md — canonical MÓDULO table
ADR 0019 — OOBI fabric
Memory: project_module_planes_classification_2026_05_10
Memory (deferred): discuss_cloud_split_control_plane_saas_2026_05_10