Skip to content

Catálogo de motores de stress

Otros idiomas: English · Português · Español

Referencia canónica de los motores de stress ortogonales que ejercitan el NGFW en paralelo a la carga principal de webservers L7. Cada motor apunta a una superficie de inspección distinta — control plane, tablas data-plane, túneles overlay, generación de paquetes — para que el operador pueda componer un test plan que stressee exactamente las partes que su perfil de procurement exige.

Por qué existen motores ortogonales

Un NGFW moderno no sólo descifra TLS. También:

  • Mantiene adyacencias BGP / OSPF que alimentan la tabla de ruteo
  • Reenvía paquetes a través de tablas MAC y ARP/NDP dimensionadas por deployment
  • Termina túneles VPN / SDWAN (IPSec, GRE, WireGuard)
  • Inspecciona tráfico encapsulado en VXLAN en deployments overlay
  • Maneja máquinas de estado de ALG / NAT / inspection profile bajo churn
  • Realiza captura de paquetes, exportación NetFlow / IPFIX y forwarding a SIEM

Stressear sólo el camino L7 de los webservers deja 6 de las 7 superficies de inspección sin medir. Los motores debajo cierran esa brecha.

Catálogo de motores

Motor Superficie de inspección Camino de código Módulo ADR de referencia
L7 primario (Caddy personas) TLS 1.2 + 1.3 · HTTP/2 · HTTP/3 / QUIC · negociación de cifra · session resumption (deshabilitado a propósito) webserver/, personas/ webservers persona · sintéticos + clonados ADR 0001
Saturación BGP Capacidad RIB de la tabla de ruteo · manejo de tormenta UPDATE · cómputo de best-path bajo churn control-plane-stress-agent/ (Go) · bgp-router-peer/ (Node) MÓDULO BGP-{1..4}.Art ADR 0012
Inyección LSA OSPF Procesamiento de LSA Tipo-1/Tipo-2/Tipo-5 · recomputación SPF · estado de adyacencia bajo churn ospf-router-peer/ (Node) · orquestación pkg/test-plan/ MÓDULO OSPF.Art ADR 0011
VPN / SDWAN On-Ramp Terminación de túnel IPSec · caminos Cloud On-Ramp / DIA · rekey de SA por túnel bajo carga escenarios SDWAN del pkg/test-plan/ · pods VyOS vpn-remote MÓDULO SDWAN CoR-{1..10}.Art —
Stress de tabla MAC / ARP Capacidad de forwarding L2 · llenado de tabla ARP / NDP · evicción CAM · saturación hash-bucket pkg/macarp-stress-agent/ (Go + gopacket) MÓDULO GO.Art ADR 0011
VTEP VXLAN (sólo TRUST) Procesamiento VTEP del underlay · lookup de VNI · throughput de encap/decap · manejo de MTU pods vyos-vtep (data plane sólo TRUST) MÓDULO VXLAN-{1..3}.Art ADR 0019
Replay de HAR (L7 aplicación) Replay realista de sesión a escala (10k sesiones/host vs ~50 del browser engine) · firing de regla WAF · detección de regresión en la capa de aplicación har-engine/ (Go) MÓDULO HAR.Art ADR 0021
DPDK stateful (line-rate) Generación de paquete userspace · 30 Mpps/core · 40M flows · TCP/UDP/IPSec stateful a line rate perfiles trex/ + trex-pod (DPDK + hugepages) MÓDULO TREX.Art ADR 0011
Baseline de throughput Comparación directa de Gbps vs números de lab del fabricante · camino de host con BBR ajustado iperf3-agent/ (binario estándar de la industria) MÓDULO IPr.Art —
Production URL Replay (PURE) Conjunto real de URLs del cliente contra el DUT · validación pre-flight DUT-delta · defensa de producción PIE-PA 3-capas pkg/test-plan/ PURE · har-engine/ · CLONER fn #9 (varios módulos) ADR 0021
Browser engine (realismo de producción) Reuso/retry/multiplex/cache reales de sesión · sondas de downgrade ALPN · HTTP/3 QUIC bajo churn genuino de sesión agent/ MÓDULO PW.Art ADR 0003
Carga programable TLS 1.3 anclado · noConnectionReuse · sólo ECDHE+AEAD · escenarios scriptables k6-agent/ MÓDULO K6.Art ADR 0006

Cómo se componen

Cada motor corre como un Deployment Kubernetes independiente, en su propia VLAN, atachado vía Multus macvlan. El NGFW bajo prueba ve:

  • Una tabla de forwarding L2 llenándose por el stress MAC/ARP
  • Una tabla de ruteo llenándose por BGP / OSPF
  • Varias sesiones paralelas de inspección desde L7 + L4 + HAR + DPDK
  • Cantidad configurable de túneles IPSec / VXLAN terminando concurrentemente

Todas las métricas fluyen al mismo stack Prometheus / Grafana / SNMP exporter. Cada motor lleva un label engine_id estable para que el operador aísle el costo por motor en los dashboards o divida el reporte por superficie.

Qué motor para cada Test Kind

Test Kind (§ ARCHITECTURE.md) Motores ejercitados
tls-throughput L7 primario + Browser engine + Carga programable + Baseline de throughput
branch-office L7 primario + Carga programable
inspection-profile L7 primario + Browser engine (comportamiento esperado por perfil)
sdwan-cor VPN/SDWAN + L7 primario (dentro del túnel) + Carga programable (dentro del túnel)
bgp-saturation Saturación BGP + Baseline de throughput (verificación de estabilidad de ruta)
mac-arp-stress Stress de tabla MAC/ARP + L7 primario (verificación de cohabitación)
pure Production URL Replay + Replay de HAR + Browser engine

Referencia rápida: cómo habilitar cada motor

Los motores se activan por test plan vía el dashboard o el schema YAML en pkg/test-plan/. Ejemplos:

# extracto del test plan YAML
engines:
  l7:
    enabled: true
    target: synthetic-personas-balanced
  bgp:
    enabled: true
    peers: 4
    prefixes_per_peer: 50_000     # → 200k entradas RIB en el DUT
  mac_arp:
    enabled: true
    rate_pps: 500
    table_target_size: 100_000
  vxlan:
    enabled: false
  har_replay:
    enabled: true
    har_source: cloned-personas/news.tlsstress.local/2026-05-12.har
    target_concurrency: 5_000
  trex_dpdk:
    enabled: false               # requiere hugepages + nodo listo para DPDK

El composer de test plan del dashboard renderiza el mismo schema como formulario; el operador puede prender/apagar motores y ajustar knobs por motor sin escribir YAML.

Profundizaciones por motor

Cada motor tiene su propio primer operativo:

Verificación — cómo confirmar que cada motor está disparando

Todo motor exporta métricas Prometheus bajo el namespace tlsstress_engine_<engine_id>. Verificaciones rápidas:

# BGP — confirmar conteo de peer + prefijos anunciados
kubectl exec -n web-agents deploy/bgp-router-peer-1 -- \
  vtysh -c 'show bgp summary'

# OSPF — confirmar adyacencia + tasa de inyección de LSA
kubectl exec -n web-agents deploy/ospf-router-peer -- \
  vtysh -c 'show ip ospf neighbor'
kubectl logs -n web-agents deploy/ospf-router-peer | grep "LSA injected"

# MAC/ARP — confirmar que el stress agent está generando tráfico
kubectl exec -n web-agents ds/macarp-stress-agent -- \
  cat /sys/class/net/net1/statistics/tx_packets   # incrementa
kubectl exec -n web-agents ds/macarp-stress-agent -- \
  ip neigh | wc -l                                 # llegando al objetivo

# L7 (primario) — confirmar pods persona sirviendo + agentes pegándoles
kubectl get pods -n persona-news -o wide
kubectl logs -n persona-news deploy/caddy --tail 20

# Replay HAR — confirmar que har-engine procesa el HAR
kubectl logs -n web-agents deploy/har-engine | grep "session_replayed"

# Baseline de throughput — confirmar iperf3 streameando
kubectl logs -n web-agents deploy/iperf3-agent | tail -20

La verificación del lado NGFW depende del fabricante — ver NGFW_CONFIGURATION_REFERENCE.es.md para el catálogo de comandos "show" por fabricante.

Estado de los motores — qué está en producción vs programado

Motor Estado en v3.7.0 Follow-up Wave-B
L7 primario ✅ en producción —
Browser engine (realismo de producción) ✅ en producción —
Carga programable ✅ en producción —
Baseline de throughput ✅ en producción —
Saturación BGP ✅ en producción —
Inyección LSA OSPF ✅ en producción (ospf-router-peer/) matriz completa de stress Type-5
Stress MAC/ARP ✅ en producción (pkg/macarp-stress-agent/) variante IPv6 NDP
Replay HAR ✅ en producción (har-engine/) detector de firing de regla WAF
VPN/SDWAN ⚠️ parcial — pods VyOS instalados, orquestación multi-túnel en marcha matriz completa IPSec + WireGuard + GRE
VTEP VXLAN ⚠️ parcial — data plane sólo TRUST en producción; stress de MTU en marcha jumbo-frame + stress por VNI
TREX DPDK ⚠️ instalado — manifiesto de pod + catálogo de perfiles; runs de line-rate exigen hardware listo para DPDK matriz completa stateful line-rate
PURE ✅ en producción (defensa PIE-PA 3-capas) feeds adicionales de URLs públicas curadas

Referencias cruzadas

  • Portafolio de patentes anclado en estos motores: Patente #18 (firma cross-language — aplica a la firma del test plan en todos los motores), reivindicaciones sobre patrones de saturación BGP / OSPF / MAC-ARP (#22-#24)
  • Postura ZTP-prem: cada motor escribe el registro de ejecución en el sealed audit hash-chain vía el gate de licencia authorize(). Ver SECURITY_ZTP_PREM.md
  • DOM (DUT Operating Mode): los motores que tocan el control plane del DUT (BGP, OSPF, VPN/SDWAN, VXLAN) son bloqueados por la cadena DDPB cuando dom=production — ver ADR 0014

Última verificación contra el código de producción: v3.7.0 (2026-05-12).