Skip to content

ADR 0047 — VXLAN is test payload only (post-ADR 0043)

  • Status: Accepted (2026-05-14)
  • Date: 2026-05-14
  • Deciders: TLSStress.Art project (operator directive 2026-05-14)
  • Supersedes / clarifies: ADR 0043
  • Targets: v4.0.0

Context

ADR 0043 retired VXLAN as the management transport for OOBI. After that change, VXLAN still exists in the codebase — but only as a test payload that the bench generates to stress the DUT (Device Under Test). Operators who haven't read ADR 0043 sometimes read the lingering references and assume VXLAN is still part of the management plane.

This ADR closes the ambiguity. There is exactly one place VXLAN is allowed in 2026+ TLSStress.Art: as a test payload generated by TREX.Art and HyperBridge.Art against the DUT's VXLAN inspection path.

Decision

Two MÓDULO classes deliberately retain VXLAN code paths:

  1. TREX.Art (canonical slot 220–221) — emits VXLAN-encapsulated stateful TCP/UDP at line rate against the DUT's south-bound port, used to validate the DUT's VXLAN-aware inspection.
  2. HyperBridge.Art (canonical slot 222–224) — inline NIC bypass tap on top of which the operator can run VXLAN-encapsulated test streams to validate the DUT's bypass-mode handling of VXLAN traffic.

The canonical slot range .76–.78 (SlotVXLAN1..3) is reserved for optional future dedicated VXLAN test-payload generators if TREX + HyperBridge prove insufficient.

Forbidden uses of VXLAN

The following uses are prohibited and any PR introducing them must be rejected at review:

  • OOBI management transport. OOBI is a plain 802.1Q VLAN (ID 2777) per ADR 0043. VXLAN VTEP DaemonSets, mDNS bootstrap, VNI 254254, the inner subnet 10.254.254.0/24 — all retired.
  • MÓDULO-to-MÓDULO data plane. Inter-MÓDULO traffic stays on the OOBI VLAN. No VXLAN overlay for control or data.
  • Hello/KeepAlive mesh. Hello packets travel on plain multicast + broadcast over the OOBI VLAN (ADR 0045). No VXLAN involved.

Wire-format references that REMAIN

The following references are legitimate VXLAN-as-test-payload semantics and must be preserved:

  • pkg/hyperbridge-art/internal/types/types.go — MTU margin comment referring to VXLAN encap overhead (test payloads emerge through the bridge with VXLAN headers).
  • pkg/hyperbridge-art/internal/netflow/types.go — datagram size cap comment (1400 < 1500 - VXLAN(50)). Conservative margin retained for DUTs that themselves do VXLAN tunneling.

Documentation updates

This ADR + ADR 0043 + ADR 0046 cited consistently across:

  • pkg/oobi/canon.go — already updated; slots 76–78 explicitly labelled "VXLAN test-payload generator (not management transport)".
  • pkg/hyperbridge-art/README.md — updated by this PR to say "OOBI VLAN sub-interface (post-ADR-0043)".
  • pkg/hyperbridge-art/systemd/config.example.json — example oobi_interface value updated from vxlan254254 → oobi0.

Consequences

Positive

  • Operators reading any file in the codebase now find at most ONE of two interpretations: VXLAN-as-OOBI-transport (forbidden) or VXLAN-as-test-payload (allowed in TREX + HyperBridge).
  • The new ADR 0046 + 0047 pair makes ADR 0043 + 0045 + 0046's intent airtight against drift.
  • Reviewers have a checkable rule for blocking VXLAN regressions.

Negative

  • One more ADR for newcomers to scan. Mitigated by the brevity of this record and its tight cross-references to 0043.

Neutral

  • No code changes required beyond the doc/comment sweeps already done in PR-OOBI-VLAN-5/6/7. Future TREX + HyperBridge VXLAN test-payload development continues as a first-class feature.

References

  • ADR 0043 — OOBI VLAN refactor (no VXLAN overlay)
  • ADR 0045 — Hello / KeepAlive mesh
  • ADR 0046 — Hello payload encryption + host_id + engaged_in_test
  • Memo: project_oobi_no_vxlan_directive_2026_05_14