Catálogo dos motores de stress¶
Outros idiomas: English · Português · Español
Referência canônica dos motores de stress ortogonais que exercitam o NGFW em paralelo à carga principal de webservers L7. Cada motor mira uma superfície de inspeção diferente — control plane, tabelas data-plane, túneis de overlay, geração de pacote — de modo que o operador possa compor um test plan que estresse exatamente as partes que o perfil de procurement dele exige.
Documentos companheiros: -
docs/DUT_TESTBED.md— operação do test bed -docs/ARCHITECTURE.md— mapa canônico dos 37 MÓDULOs -docs/NGFW_CONFIGURATION_REFERENCE.pt-BR.md— configurações por fabricante
Por que existem motores ortogonais¶
Um NGFW moderno não apenas decripta TLS. Ele também:
- Mantém adjacências BGP / OSPF que alimentam a tabela de roteamento
- Encaminha pacotes através de tabelas MAC e ARP/NDP dimensionadas pelo deployment
- Termina túneis VPN / SDWAN (IPSec, GRE, WireGuard)
- Inspeciona tráfego encapsulado em VXLAN em deployments de overlay
- Trata máquinas de estado de ALG / NAT / inspection profile sob churn
- Faz captura de pacotes, exportação NetFlow / IPFIX e encaminhamento para SIEM
Stressar apenas o caminho L7 dos webservers deixa 6 das 7 superfícies de inspeção sem medição. Os motores abaixo fecham essa lacuna.
Catálogo de motores¶
| Motor | Superfície de inspeção | Caminho de código | Módulo | ADR de referência |
|---|---|---|---|---|
| L7 primário (Caddy personas) | TLS 1.2 + 1.3 · HTTP/2 · HTTP/3 / QUIC · negociação de cifra · session resumption (desativado de propósito) | webserver/, personas/ |
webservers persona · sintéticos + clonados | ADR 0001 |
| Saturação BGP | Capacidade RIB da tabela de roteamento · tratamento de tempestade de UPDATE · cômputo de best-path sob churn | control-plane-stress-agent/ (Go) · bgp-router-peer/ (Node) |
MÓDULO BGP-{1..4}.Art | ADR 0012 |
| Injeção LSA OSPF | Processamento de LSA Tipo-1/Tipo-2/Tipo-5 · recomputação SPF · estado de adjacência sob churn | ospf-router-peer/ (Node) · orquestração via pkg/test-plan/ |
MÓDULO OSPF.Art | ADR 0011 |
| VPN / SDWAN On-Ramp | Terminação de túnel IPSec · caminhos Cloud On-Ramp / DIA · rekey de SA por túnel sob carga | cenários SDWAN do pkg/test-plan/ · pods VyOS vpn-remote |
MÓDULO SDWAN CoR-{1..10}.Art | — |
| Stress de tabela MAC / ARP | Capacidade de forwarding L2 · preenchimento de tabela ARP / NDP · evicção CAM · saturação de hash-bucket | pkg/macarp-stress-agent/ (Go + gopacket) |
MÓDULO GO.Art | ADR 0011 |
| VTEP VXLAN (só TRUST) | Processamento VTEP do underlay · lookup de VNI · throughput de encap/decap · MTU handling | pods vyos-vtep (data plane só TRUST) |
MÓDULO VXLAN-{1..3}.Art | ADR 0019 |
| Replay de HAR (L7 aplicação) | Replay realista de sessão em escala (10k sessões/host vs ~50 do browser engine) · firing de regra WAF · detecção de regressão na camada de aplicação | har-engine/ (Go) |
MÓDULO HAR.Art | ADR 0021 |
| DPDK stateful (line-rate) | Geração de pacote em userspace · 30 Mpps/core · 40M flows · TCP/UDP/IPSec stateful em line rate | perfis trex/ + trex-pod (DPDK + hugepages) |
MÓDULO TREX.Art | ADR 0011 |
| Baseline de throughput | Comparação direta de Gbps vs números de lab do fabricante · caminho de host com BBR tunado | iperf3-agent/ (binário padrão da indústria) |
MÓDULO IPr.Art | — |
| Production URL Replay (PURE) | Conjunto real de URLs do cliente contra o DUT · validação pré-flight DUT-delta · defesa de produção PIE-PA 3-camadas | pkg/test-plan/ PURE · har-engine/ · CLONER fn #9 |
(vários módulos) | ADR 0021 |
| Browser engine (realismo de produção) | Reuso/retry/multiplex/cache reais de sessão · sondas de downgrade ALPN · HTTP/3 QUIC sob churn genuíno de sessão | agent/ |
MÓDULO PW.Art | ADR 0003 |
| Carga programável | TLS 1.3 pinado · noConnectionReuse · só ECDHE+AEAD · cenários scriptáveis | k6-agent/ |
MÓDULO K6.Art | ADR 0006 |
Como eles compõem¶
Cada motor roda como um Deployment Kubernetes independente, em VLAN própria, atachado via Multus macvlan. O NGFW sob teste vê:
- Uma tabela de forwarding L2 sendo preenchida pelo stress MAC/ARP
- Uma tabela de roteamento sendo preenchida por BGP / OSPF
- Várias sessões paralelas de inspeção a partir de L7 + L4 + HAR + DPDK
- Quantidade configurável de túneis IPSec / VXLAN terminando concorrentemente
Todas as métricas fluem para a mesma stack Prometheus / Grafana /
SNMP exporter. Cada motor carrega um label engine_id estável
para o operador isolar custo por motor nos dashboards ou separar
o relatório por superfície.
Qual motor para cada Test Kind¶
| Test Kind (§ ARCHITECTURE.md) | Motores exercitados |
|---|---|
tls-throughput |
L7 primário + Browser engine + Carga programável + Baseline de throughput |
branch-office |
L7 primário + Carga programável |
inspection-profile |
L7 primário + Browser engine (comportamento esperado por perfil) |
sdwan-cor |
VPN/SDWAN + L7 primário (dentro do túnel) + Carga programável (dentro do túnel) |
bgp-saturation |
Saturação BGP + Baseline de throughput (verificação de estabilidade de rota) |
mac-arp-stress |
Stress de tabela MAC/ARP + L7 primário (verificação de coabitação) |
pure |
Production URL Replay + Replay de HAR + Browser engine |
Referência rápida: como habilitar cada motor¶
Motores são ativados por test plan via o dashboard ou pelo schema
YAML em pkg/test-plan/. Exemplos:
# trecho do test plan YAML
engines:
l7:
enabled: true
target: synthetic-personas-balanced
bgp:
enabled: true
peers: 4
prefixes_per_peer: 50_000 # → 200k entradas RIB no 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 # exige hugepages + nó pronto pra DPDK
O composer de test plan do dashboard renderiza o mesmo schema como um formulário; o operador pode ligar/desligar motores e ajustar knobs por motor sem escrever YAML.
Aprofundamentos por motor¶
Cada motor tem seu próprio primer operacional:
- Saturação BGP —
docs/help-center/primers/bgp-saturation.md - Injeção LSA OSPF —
docs/help-center/primers/ospf-lsa-injection.md - Stress MAC / ARP —
docs/help-center/primers/mac-arp-stress.md - VPN / SDWAN On-Ramp —
docs/help-center/primers/vpn-sdwan-onramp.md - VTEP VXLAN (só TRUST) —
docs/help-center/primers/vxlan-vtep.md - Replay HAR —
docs/help-center/primers/har-replay.md - TREX DPDK —
docs/help-center/primers/trex-dpdk.md - PURE —
docs/help-center/primers/pure-production-url-replay.md(operador) + ADR 0021 (design)
Verificação — como confirmar que cada motor está disparando de verdade¶
Todo motor exporta métricas Prometheus sob o namespace
tlsstress_engine_<engine_id>. Verificações rápidas:
# BGP — confirmar contagem de peer + prefixos anunciados
kubectl exec -n web-agents deploy/bgp-router-peer-1 -- \
vtysh -c 'show bgp summary'
# OSPF — confirmar adjacência + taxa de injeção 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 o stress agent está gerando tráfego
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 # chegando no alvo
# L7 (primário) — confirmar pods persona servindo + agentes batendo
kubectl get pods -n persona-news -o wide
kubectl logs -n persona-news deploy/caddy --tail 20
# Replay HAR — confirmar que har-engine está processando o HAR
kubectl logs -n web-agents deploy/har-engine | grep "session_replayed"
# Baseline de throughput — confirmar iperf3 streamando
kubectl logs -n web-agents deploy/iperf3-agent | tail -20
A verificação no lado do NGFW depende do fabricante — ver
NGFW_CONFIGURATION_REFERENCE.pt-BR.md
para o catálogo de comandos "show" por fabricante.
Status dos motores — o que está em produção vs agendado¶
| Motor | Status em v3.7.0 | Follow-up Wave-B |
|---|---|---|
| L7 primário | ✅ em produção | — |
| Browser engine (realismo de produção) | ✅ em produção | — |
| Carga programável | ✅ em produção | — |
| Baseline de throughput | ✅ em produção | — |
| Saturação BGP | ✅ em produção | — |
| Injeção LSA OSPF | ✅ em produção (ospf-router-peer/) |
matriz completa de stress Type-5 |
| Stress MAC/ARP | ✅ em produção (pkg/macarp-stress-agent/) |
variante IPv6 NDP |
| Replay HAR | ✅ em produção (har-engine/) |
detector de firing de regra WAF |
| VPN/SDWAN | ⚠️ parcial — pods VyOS instalados, orquestração multi-túnel em andamento | matriz completa IPSec + WireGuard + GRE |
| VTEP VXLAN | ⚠️ parcial — data plane só TRUST em produção; stress de MTU em andamento | jumbo-frame + stress por VNI |
| TREX DPDK | ⚠️ instalado — manifesto de pod + catálogo de perfis; runs de line-rate exigem hardware pronto pra DPDK | matriz completa stateful line-rate |
| PURE | ✅ em produção (defesa PIE-PA 3-camadas) | feeds adicionais de URLs públicas curadas |
Referências cruzadas¶
- Portfólio de patentes ancorado nestes motores: Patente #18 (assinatura cross-language — aplica-se à assinatura do test plan em todos os motores), reivindicações sobre padrões de saturação BGP / OSPF / MAC-ARP (#22-#24)
- Postura ZTP-prem: todo motor escreve o registro de execução no
sealed audit hash-chain via o gate de licença
authorize(). Ver SECURITY_ZTP_PREM.md - DOM (DUT Operating Mode): motores que tocam o control plane do
DUT (BGP, OSPF, VPN/SDWAN, VXLAN) são bloqueados pela cadeia
DDPB quando
dom=production— ver ADR 0014
Última verificação contra o código de produção: v3.7.0 (2026-05-12).