Skip to content

Modos de Prueba con NAT

Lee en tu idioma: English · Português · Español

Estado del alcance (post-congelación de alcance 2026-05-10) — Ver ARCHITECTURE.md para los 37 MÓDULOs canónicos + 7 Test Kinds + arquitectura de safety DOM/CPOS/PIE-PA. ADRs 0014, 0019-0025 cubren adiciones post-Freeze.

Estado: Fundación en v4.3 — ADR 0007 §16 (matriz) + §22 (orquestador) + §26 (Anexo H + I).

Por qué probar ambos modos

La capacidad del NGFW en producción está determinada por dos costos de CPU largamente independientes: descifrado TLS y traducción NAT. Los clientes frecuentemente atribuyen los límites de throughput al decrypt cuando el cuello de botella real es el NAT, o vice versa. Una prueba que solo ejecuta la configuración de producción no puede descomponer estos dos costos.

Este test-bed ejercita el NGFW en dos modos NAT:

  • nat_mode: pat — source-PAT (NAT Overload). NGFW mantiene una tabla de traducción y reescribe IP/puerto source para cada flow. Realista para producción; pesado en CPU y memoria.
  • nat_mode: disabled — forwarding puramente ruteado. NGFW solo inspecciona y reenvía; sin traducción, sin tabla xlate. Throughput máximo teórico del device bajo carga de decrypt.

Cada test plan declara qué modo necesita. La DUT API (dashboard/src/lib/dut-api/) aplica la config vendor-specific correspondiente antes que el run inicie y revierte al final.

Qué cambia dentro del NGFW

Aspecto nat_mode: pat nat_mode: disabled
Escrituras en la tabla de traducción Sí — cada nuevo flow consume una entrada xlate Ninguna
Reescrituras source/dest Reescritura IP + puerto source por paquete Pass-through
Inflación del conntrack Alta — cada flow NAT'd toma una entrada conntrack Baja — solo state de inspección
Perfil de CPU (típico) NAT engine 15–25%, crypto 40–55%, inspección 15–20% NAT engine 0%, crypto 50–60%, inspección 25–30%
Penalty de throughput 15–30% vs baseline nat_mode: disabled Baseline de referencia
Modo de falla Agotamiento del pool bajo estrés (resultados invalidados) Límite de conexión / backlog de inspección

Cuándo elegir cada modo

Escenario Modo recomendado
Cliente comissionando NGFW nuevo para capacity planning Ambos — ejecuta el plan MATRIX (CAP-FIND-KNEE-MATRIX-2H) para descomposición completa por cuadrante
Sanity check rápido (config válida, decrypt funcionando) nat_mode: disabled (Q1 baseline) — más rápido, menos variables
Prueba full mirror de producción nat_mode: pat (Q4)
Aislar costo del NAT engine vs crypto engine nat_mode: disabled + decrypt: on (Q2) Y nat_mode: pat + decrypt: off (Q3); comparar deltas
Probar decisión de NAT pool sizing nat_mode: pat con pool reducido — verifica que exhaustion dispare alertas esperadas

La matriz 2×2 de cuadrantes

El plan MATRIX (CAP-FIND-KNEE-MATRIX-2H) orquesta cuatro sub-runs de 30 minutos secuencialmente:

                         SIN NAT                  CON NAT
                  ┌───────────────────────┬───────────────────────┐
   SIN            │ Q1 Baseline           │ Q3 NAT-only           │
   DECRYPT        │ forward puro          │ aísla costo NAT       │
                  ├───────────────────────┼───────────────────────┤
   CON            │ Q2 Decrypt-only       │ Q4 Producción         │
   DECRYPT        │ aísla costo crypto    │ NAT + decrypt         │
                  └───────────────────────┴───────────────────────┘

El resultado es un único Test Run Report conteniendo Anexo I — Descomposición de Capacidad por Cuadrante con aritmética de delta (NAT solo, decrypt solo, combinado, bonus de sinergia) y guidance de optimización customer-facing.

Ver dashboard/templates/annex-i-quadrant-decomposition.md.tmpl para el layout completo del anexo.

Tuning vendor-específico (per nat_pool_overload: tuned)

Cuando un plan declara nat_pool_overload: tuned, la DUT API aplica estos tunings por vendor antes que el run inicie. Templates están en dashboard/src/lib/dut-api/<vendor>/templates/nat_pat.tmpl.

Cisco FTD (cdFMC / FMC)

Setting Valor tuneado Por qué
xlate-timeout 180s (vs default 3600s) Devuelve entradas de traducción al pool más rápido en runs de stress
tcp-halfclose-timer 15s (vs default 60s) Libera flows pendientes de TCP-RST/FIN rápidamente
nat-protocol-table-size máximo per-platform (ej., 4M en FTD 4115) Maximiza capacidad del pool
nat-rule-prioritization habilitado Evita fragmentación del pool bajo churn pesado

Fortinet FortiGate

Setting Valor tuneado Por qué
tcp-timewait-timer 30 Libera sockets TIME_WAIT rápidamente
tcp-halfclose-timer 15 Libera closes TCP pendientes rápidamente
port-block-allocation enable Reduce pool exhaustion en CPS alto
central-snat-policy una regla wide-net (vs muchas específicas) Reduce overhead de lookup

Palo Alto Networks (PAN-OS)

Setting Valor tuneado Por qué
dynamic-ip-and-port translation timeout 180s Reciclaje agresivo
tcp half-closed timeout 15s Igual que FTD
oversubscription habilitado con rate 4 Permite 4× más traducciones NAT concurrentes por IP público

Los valores efectivos usados en cualquier run específico se graban en Anexo H — Performance del NAT Engine, sub-sección H.1 (vendor_template_id + vendor_template_sha256), para que reviewers puedan verificar que el tuning fue aplicado conforme documentado.

Leyendo las alertas (anchors de runbook)

Las alertas Prometheus en k8s/dut/96-nat-engine-rules.yaml cargan annotations runbook_url apuntando a este documento. Cada anchor abajo es el runbook para la alerta correspondiente.

Pool utilization warning

Disparado por NATPoolUtilizationHigh cuando pool > 80% sostenido por 30s.

Qué significa: NAT pool aproximándose al exhaustion bajo carga actual.

Respuesta del operador: 1. Chequea el dashboard NAT engine (Grafana → dut-nat-engine) para trayectoria — utilización subiendo o estable? 2. Si subiendo y run es long-running (soak / 8h): considera parar el run y re-correr con fleet más pequeña. 3. Si estable en 80–90% durante toda la prueba: capacity claim es válido pero el cliente debe saber que ese modelo NGFW se agotaría con carga ligeramente mayor.

Opción de tuning: bajar xlate-timeout a 60s (Cisco FTD) o tcp-timewait-timer a 15s (Fortinet) — recicla entradas del pool más rápido.

Pool exhaustion

Disparado por NATPoolExhaustion cuando cualquier evento de exhaustion ocurre en el último 1m.

Qué significa: NGFW silenciosamente dropeó al menos una solicitud de traducción porque el pool estaba lleno. Resultados de la prueba invalidados — el test bed está midiendo falla, no capacidad.

Respuesta del operador: 1. Para el run inmediatamente si todavía está activo. 2. Anexo H del reporte va a marcar ese run como invalidado con el conteo de eventos de exhaustion. 3. Aumenta el NAT pool size en el DUT API NAT template (vendor-specific). 4. Re-corre con configuración corregida.

Guidance de root cause: con 1000 synthetic-load agents × ~10 conexiones/sec × 30 min = ~18M flows; si tu pool es < 4M entradas con xlate-timeout: 3600s, exhaustion es matemáticamente inevitable. El template nat_pool_overload: tuned aborda esto — verifica que fue aplicado (Anexo H §H.1).

Translation timeout spike

Disparado por NATTranslationTimeoutSpike cuando rate de timeout de traducción > 100/sec sostenido por 1m.

Qué significa: Muchos flows están siendo aged out por el xlate-timeout en lugar de cerrados naturalmente (RST/FIN). Indica flows cortos sosteniendo entradas xlate más allá de su vida natural.

Respuesta del operador: 1. No invalida el run; severidad informativa. 2. Tunea NAT template para próximo run: - Cisco FTD: bajar xlate-timeout a 60s (combina con pattern de burst del synthetic-load engine) - Fortinet: bajar tcp-halfclose-timer a 15s (libera closes pendientes más rápido) 3. Re-corre; espera CPS mensurable mayor sin retunear agents.

Cómo interpretar Anexo H + I en el reporte

Anexo H — Performance del NAT Engine (renderizado para runs nat_mode: pat)

  • §H.1 Configuración aplicada — el template NAT + valores de tuning usados. Verifica que combinen con lo que intencionaste (y lo que el NGFW de producción del cliente usa).
  • §H.2 Métricas runtime — pool peak utilization es el número headline. Algo arriba de 80% es flag amarilla; eventos de exhaustion > 0 es flag roja.
  • §H.3 Correlación de capacidad — breakdown de CPU revela donde el engine está limitado. Slice de NAT >25% significa que NAT es cuello de botella significativo; <10% significa que NAT es esencialmente gratis para ese NGFW.

Anexo I — Descomposición de Capacidad por Cuadrante (renderizado para runs type: matrix)

  • §I.2 Tabla de descomposición — los cuatro números (NAT solo, decrypt solo, combinado, sinergia) son la respuesta principal para el cliente. Sinergia cerca de cero significa NAT y decrypt son caminos de CPU ortogonales.
  • §I.3 Adónde va la CPU — breakdown de CPU por cuadrante. Esa es la slide que el arquitecto de red del cliente va a screenshotear.
  • §I.4 Customer guidance — caminos de optimización rankeados. Usa eso verbatim en el briefing customer-facing.

Referencia de plans

Plan identifier Modo Duración Caso de uso
CAP-FIND-KNEE-30M-Q1 nat: disabled, decrypt: off 30 min Baseline; primer run de cualquier engagement
CAP-FIND-KNEE-30M-Q2 nat: disabled, decrypt: on 30 min Costo de decrypt en aislamiento
CAP-FIND-KNEE-30M-Q3 nat: pat, decrypt: off 30 min Costo de NAT en aislamiento
CAP-FIND-KNEE-30M-Q4 nat: pat, decrypt: on 30 min Escenario de producción
CAP-FIND-KNEE-MATRIX-2H Los cuatro secuencialmente 2 horas Descomposición completa por cuadrante

Ver platform/test-plans/catalog.yaml para las definiciones canónicas.

Relacionados