Prueba de Rendimiento NGFW — Checklist de Inicio Rápido¶

Para quién es este documento: cualquier persona que configure el TLSStress.Art para ejecutar una prueba de rendimiento de inspección TLS en un NGFW físico por primera vez. No se requiere experiencia previa con Kubernetes — cada comando está listo para copiar.

Tiempo estimado: ~2 horas (cableado + configuración del NGFW + instalación del software)

Autor: André Luiz Gallon — agallon@Cisco.com | Versión: v3.6.0

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.

Antes de Comenzar — Lo que Necesita¶

Hardware¶

1 servidor Ubuntu (host del test-bed) — Ubuntu 22.04 LTS, mínimo 8 núcleos / 32 GB RAM / 100 GB de disco
1 Cisco Nexus 9000 (o cualquier switch administrable con trunking 802.1q)
1 NGFW (el dispositivo que se va a probar — Cisco FTD, FortiGate, Palo Alto, Check Point, etc.)
Cables de red: 2–3 cables entre Ubuntu ↔ Nexus; 2 cables entre Nexus ↔ NGFW

Software (en el servidor Ubuntu)¶

Ubuntu 22.04 LTS instalado y accesible por SSH
Acceso sudo en el servidor Ubuntu
git instalado: sudo apt-get install -y git

Conocimiento requerido¶

Sabe acceder a un servidor Linux por SSH
Sabe iniciar sesión en la interfaz web o CLI de su NGFW
Conoce la CA de interceptación de su NGFW (la CA que usa para re-firmar certificados HTTPS en la inspección TLS)

Fase 1 — Cablear el Hardware¶

Paso 1 — Conectar el servidor Ubuntu al Nexus 9000¶

Conecte eth1 en el servidor Ubuntu a un puerto trunk en el Nexus 9000.

Ubuntu eth1 ──── (trunk, todas las VLANs) ──── Nexus 9000

eth0 en Ubuntu es para SSH y gestión — NO lo use para tráfico de prueba.

Paso 2 — Conectar el NGFW al Nexus 9000¶

Conecte dos cables: uno para la interfaz inside del NGFW (lado de los agentes) y uno para la outside (lado de los webservers).

Nexus 9000 ──── (trunk VLANs 20,30) ──── NGFW inside
Nexus 9000 ──── (trunk VLANs 101-120) ── NGFW outside

Opcionalmente conecte un tercer cable para gestión SNMP (VLAN 99).

Fase 2 — Configurar el Nexus 9000¶

Paso 3 — Configurar VLANs y puertos trunk en el Nexus 9000¶

Acceda al Nexus 9000 por SSH o consola y ejecute:

configure terminal

! Crear todas las VLANs
vlan 20,30,99,101-120
  name test-vlans
exit

! Trunk hacia el servidor Ubuntu
interface <interface-hacia-ubuntu>
  switchport mode trunk
  switchport trunk allowed vlan 20,30,99,101-120
  no shutdown
exit

! Trunk hacia el NGFW inside (agentes)
interface <interface-hacia-ngfw-inside>
  switchport mode trunk
  switchport trunk allowed vlan 20,30
  no shutdown
exit

! Trunk hacia el NGFW outside (webservers)
interface <interface-hacia-ngfw-outside>
  switchport mode trunk
  switchport trunk allowed vlan 101-120
  no shutdown
exit

! Opcional: access port para gestión SNMP del NGFW
interface <interface-hacia-ngfw-mgmt>
  switchport mode access
  switchport access vlan 99
  no shutdown
exit

copy running-config startup-config

Reemplace <interface-hacia-...> con los nombres reales de sus interfaces (p. ej., Ethernet1/1, Ethernet1/2, Ethernet1/3).

Resultado esperado: show vlan brief muestra las VLANs 20, 30, 99, 101–120 como activas.

Fase 3 — Instalar el Software en Ubuntu¶

Paso 4 — Clonar el repositorio¶

git clone https://github.com/nollagluiz/AI_forSE.git
cd AI_forSE

Paso 5 — Ejecutar el instalador automatizado¶

sudo bash scripts/k8s-install.sh --mode=single --data-iface=eth1

Este comando instala k3s, Helm, cert-manager, Multus CNI, configura subinterfaces 802.1q en eth1 y despliega el web agent cluster completo. Tarda aproximadamente 15–20 minutos.

¿Tiene más de un UCS disponible? Este checklist sigue el camino single-node (un único host Ubuntu corre todo). Existen tres modos de deployment adicionales: - Dual-node (2 UCS) — UCS-1 corre la flota de agentes, UCS-2 corre personas + servicios. Vea UBUNTU_K3S_DUALNODE_QUICKSTART_DEPLOY.es.md. - Tri-node (3 UCS) — UCS-1 = browser engine, UCS-2 = synthetic-load engine, UCS-3 = personas + servicios. Añade aislamiento de runtime entre los dos tipos de agente. Vea UBUNTU_K3S_TRINODE_QUICKSTART_DEPLOY.es.md. - Multi-node (4 UCS) — un rol por UCS, máximo throughput. Vea UBUNTU_K3S_MULTINODE_QUICKSTART_DEPLOY.es.md.

Todas las alternativas usan k8s-install.sh con flags --mode diferentes. El resto de este checklist (PKI del NGFW, verificación, ejecución de la prueba) aplica a los cuatro modos — solo cambia la Fase 3.

Resultado esperado al final del script:

[OK] k3s cluster is running
[OK] cert-manager is ready
[OK] Multus is ready
[OK] TLSStress.Art deployed
[OK] All pods are Running

Paso 6 — Verificar que todos los pods están corriendo¶

kubectl get pods -n web-agents

Todos los pods deben aparecer como Running o Completed. Si alguno está en Pending o Error, espere 2 minutos más y vuelva a intentar.

kubectl get pods -n web-agents --watch
# Presione Ctrl+C cuando todos los pods muestren Running

Paso 7 — Activar el modo DUT (pone el NGFW en el camino de datos)¶

sudo bash scripts/k8s-dut-up.sh up

Resultado esperado:

[OK] DUT overlay applied
[OK] PKI ready (persona-ca issued)
[OK] Caddy pods running with macvlan net1
[OK] DUT mode active

Fase 4 — Intercambio de Certificados PKI (el paso más importante)¶

Esta fase configura la confianza mutua de certificados entre el cluster y el NGFW. No omita esta fase.

Paso 8 — Exportar persona-ca del cluster → importar en el NGFW¶

Esta CA firma todos los certificados de las personas (20 Synthetic + 10 Cloned slots). El NGFW debe confiar en ella para validar las conexiones TLS del Leg 2.

8a. Exportar la CA del cluster:

kubectl get secret persona-ca -n web-agents \
  -o jsonpath='{.data.ca\.crt}' | base64 -d > /tmp/persona-ca.pem

# Confirmar que parece un certificado válido
openssl x509 -in /tmp/persona-ca.pem -noout -subject -dates

Salida esperada:

subject=O=TLSStress.Art, OU=DUT Lab, CN=Persona CA
notBefore=<fecha>
notAfter=<fecha 10 años después>

8b. Copiar el archivo a su laptop:

# Desde su laptop (no desde el servidor):
scp ubuntu@<ip-del-servidor>:/tmp/persona-ca.pem ~/Downloads/persona-ca.pem

8c. Importar en el NGFW — use los pasos de su fabricante en docs/NGFW_CONFIGURATION_REFERENCE.es.md, sección 8. En general:

Fabricante	Dónde importar
Cisco FTD (FMC)	Objects → PKI → Trusted CAs → Add Trusted CA
Cisco FTD (FDM)	Objects → Certificates → Trusted CA → Add
Cisco ASA	`crypto ca authenticate DUT-ROOT-CA` (pegar el PEM)
FortiGate	Security Profiles → SSL/SSH Inspection → CA Certificate
Palo Alto	Device → Certificate Management → Certificates → Import (marcar como Trusted Root CA)
Check Point	SmartConsole → Objects → Certificate Authority → Trusted CA

Paso 9 — Exportar ngfw-ca del NGFW → instalar en el cluster¶

Esta es la CA de interceptación propia del NGFW. Los agentes deben confiar en ella para aceptar los certificados re-firmados por el NGFW.

9a. Exportar del NGFW (consulte la sección 6.2 de la referencia NGFW para su fabricante). Guárdela como ngfw-ca.pem en su laptop.

9b. Copiar al servidor Ubuntu:

# Desde su laptop:
scp ~/Downloads/ngfw-ca.pem ubuntu@<ip-del-servidor>:/tmp/ngfw-ca.pem

9c. Instalar en el cluster:

kubectl create configmap ngfw-ca \
  -n web-agents \
  --from-file=ngfw-ca.crt=/tmp/ngfw-ca.pem \
  --dry-run=client -o yaml | kubectl apply -f -

9d. Reiniciar los agentes para cargar la nueva CA:

kubectl rollout restart deployment/web-agent -n web-agents
kubectl rollout restart deployment/k6-agent  -n web-agents

# Esperar a que el reinicio complete
kubectl rollout status deployment/web-agent -n web-agents
kubectl rollout status deployment/k6-agent  -n web-agents

Salida esperada:

deployment "web-agent" successfully rolled out
deployment "k6-agent" successfully rolled out

Fase 5 — Configurar el NGFW¶

Paso 10 — Configurar subinterfaces de VLAN en el NGFW¶

Para cada VLAN en la tabla siguiente, cree una subinterfaz con la dirección IP indicada. Consulte la sección 8 de docs/NGFW_CONFIGURATION_REFERENCE.es.md para los pasos específicos de su fabricante.

VLAN	IP a configurar en el NGFW	Propósito
20	`172.16.0.1/16`	Gateway de los agentes browser engine
30	`172.17.0.1/16`	Gateway de los agentes synthetic-load engine
99	`192.168.90.3/24`	Monitoreo SNMP (opcional)
101	`10.1.1.1/27`	Gateway de la persona shop
102	`10.1.2.1/27`	Gateway de la persona news
103	`10.1.3.1/27`	Gateway de la persona blog
104	`10.1.4.1/27`	Gateway de la persona docs
105	`10.1.5.1/27`	Gateway de la persona gallery
106	`10.1.6.1/27`	Gateway de la persona stream
107	`10.1.7.1/27`	Gateway de la persona download
108	`10.1.8.1/27`	Gateway de la persona edu
109	`10.1.9.1/27`	Gateway de la persona gov
110	`10.1.10.1/27`	Gateway de la persona cdn
111	`10.1.11.1/27`	Gateway de la persona api-rest
112	`10.1.12.1/27`	Gateway de la persona api-graphql
113	`10.1.13.1/27`	Gateway de la persona chat
114	`10.1.14.1/27`	Gateway de la persona webhook
115	`10.1.15.1/27`	Gateway de la persona telemetry
116	`10.1.16.1/27`	Gateway de la persona ads
117	`10.1.17.1/27`	Gateway de la persona har-saas
118	`10.1.18.1/27`	Gateway de la persona har-social
119	`10.1.19.1/27`	Gateway de la persona har-webmail
120	`10.1.20.1/27`	Gateway de la persona har-media

Paso 11 — Crear zonas de seguridad en el NGFW¶

Zona	Asignar VLANs
`agents`	VLAN 20, VLAN 30
`personas`	VLANs 101–120

Paso 12 — Crear la política de inspección TLS en el NGFW¶

Cree una política que descifre e inspeccione todo el tráfico HTTPS de los agentes a las personas:

Regla	Origen	Destino	Puertos	Acción
Inspeccionar todo	`172.16.0.0/16`, `172.17.0.0/16`	`10.1.0.0/16`	TCP 443, UDP 443	Descifrar e Inspeccionar

Use la persona-ca importada en el paso 8 como CA de confianza para conexiones salientes (Leg 2)
Use la CA de interceptación del NGFW (exportada en el paso 9) para re-firmar certificados a los agentes (Leg 1)

Fase 6 — Verificar que Todo Funciona¶

Paso 13 — Verificar que el gateway del NGFW es accesible desde los agentes¶

# Entrar en un pod de agente browser-engine
kubectl exec -it -n web-agents deployment/web-agent -- sh

# Hacer ping al gateway del NGFW
ping -c 3 172.16.0.1

Salida esperada:

3 packets transmitted, 3 received, 0% packet loss

Si los pings fallan: verifique que la VLAN 20 esté configurada en el trunk del Nexus hacia Ubuntu y en la interfaz inside del NGFW.

Paso 14 — Verificar que la inspección TLS está activa¶

# Aún dentro del pod de agente:
echo | openssl s_client -connect shop.persona.internal:443 \
  -servername shop.persona.internal 2>/dev/null \
  | openssl x509 -noout -issuer -subject

Esperado (inspección TLS funcionando):

issuer=CN=<Nombre de su CA de interceptación NGFW>
subject=CN=shop.persona.internal

Problema (inspección TLS NO funcionando — NGFW fuera del camino):

issuer=CN=Persona CA
subject=CN=shop.persona.internal

Si el emisor es Persona CA, el NGFW no está interceptando el tráfico. Verifique: la política TLS del NGFW está desplegada, las zonas son correctas, el tráfico está enrutando a través del NGFW.

Problema (error de certificado):

SSL certificate verify error: unable to get local issuer certificate

Si ve un error de certificado, la ngfw-ca no está instalada o los agentes no fueron reiniciados. Repita el paso 9.

Paso 15 — Verificar que las 20 personas son accesibles¶

# Dentro del pod de agente:
for persona in shop news blog docs gallery stream download edu gov cdn \
               api-rest api-graphql chat webhook telemetry ads \
               har-saas har-social har-webmail har-media; do
  code=$(curl -sk -o /dev/null -w "%{http_code}" \
    https://${persona}.persona.internal/ --max-time 3)
  echo "${persona}: HTTP ${code}"
done

Esperado: las 20 personas devuelven HTTP 200. Cualquier 000 indica que la persona es inaccesible (verifique el ruteo del NGFW para esa VLAN).

Fase 7 — Ejecutar la Prueba y Leer los Resultados¶

Paso 16 — Abrir el dashboard¶

El dashboard corre en el puerto 3000 del servidor Ubuntu:

http://<ip-del-servidor-ubuntu>:3000

Desde el dashboard puede: - Ver qué personas están activas (verde = corriendo, rojo = error) - Iniciar/detener la carga browser engine y synthetic-load engine - Ajustar el número de sesiones de agente simultáneas

Paso 17 — Iniciar la prueba de carga¶

Desde el dashboard, haga clic en Start Test o use la CLI:

# Iniciar agentes browser-engine (simulación de navegador real)
kubectl scale deployment/web-agent -n web-agents --replicas=10

# Iniciar agentes synthetic-load (carga HTTP)
kubectl scale deployment/k6-agent -n web-agents --replicas=5

Aumente las réplicas gradualmente para incrementar la carga.

Paso 18 — Abrir Grafana para ver las métricas de rendimiento¶

Grafana corre en el puerto 3001:

http://<ip-del-servidor-ubuntu>:3001

Credenciales por defecto: admin / admin (cámbielas en el primer inicio de sesión)

Dashboards clave para monitorear:

Dashboard	Qué muestra	Qué observar
TLS Throughput	MB/s de tráfico inspeccionado	Caídas bajo carga = cuello de botella en NGFW
TLS Latency	ms añadidos por conexión por la inspección	Picos = CPU del NGFW bajo presión
HTTP/3 vs HTTP/2	Comparación QUIC vs TCP	Tasa de caída QUIC = límite de soporte QUIC del NGFW
Error Rate	% de conexiones descartadas	>1% de error = NGFW sobrecargado
NGFW CPU (SNMP)	Utilización de CPU del NGFW	Correlacione CPU% con caídas de throughput

Paso 19 — Interpretar los resultados¶

Métrica	Buen resultado	Advertencia	Crítico
TLS Throughput	Estable en el objetivo	Caída gradual	Caída repentina >20%
Latencia TLS añadida	< 5ms por conexión	5–20ms	> 20ms
Tasa de error	< 0,1%	0,1–1%	> 1%
CPU del NGFW	< 70%	70–85%	> 85% (throttling)

Los resultados muestran la capacidad máxima de inspección TLS del NGFW antes de que el rendimiento se degrade.

Limpieza — Detener la Prueba¶

Paso 20 — Reducir los agentes a cero¶

kubectl scale deployment/web-agent -n web-agents --replicas=0
kubectl scale deployment/k6-agent  -n web-agents --replicas=0

Paso 21 — Desactivar el modo DUT (opcional)¶

sudo bash scripts/k8s-dut-up.sh down

Paso 23 — Aplicar tuning del host en CADA nodo¶

OBLIGATORIO para las stacks Synthetic Persona y Cloned Persona. Sin este tuning los buffers UDP del kernel limitan QUIC a ~30 Mbps por réplica y cwnd TCP se resetea en cada ventana idle de HTTP/2. También válido para UCS-2/UCS-3 (flota de agentes) — sin estos sysctls, 1000 réplicas synthetic-load engine agotan la tabla conntrack y los agentes empiezan a reportar "TCP connect timeout" aleatorios.

# UCS-1 (personas + slots) y UCS-4 (Cloner + NFS) — Guaranteed QoS, con pinning:
sudo scripts/host-tuning.sh apply --enable-cpu-pinning

# UCS-2 (browser engine) y UCS-3 (synthetic-load engine) — Burstable QoS, SIN pinning:
sudo scripts/host-tuning.sh apply

# Verificar en cada nodo (reporte coloreado)
sudo scripts/host-tuning.sh status

--enable-cpu-pinning activa cpuManagerPolicy: static en el kubelet y reinicia el kubelet — planee una ventana. No usar en hosts de agentes (HPA escala 1→300/1000 réplicas, cores exclusivos serían desperdicio). Detalles en PERFORMANCE_TUNING_HOST.md.

Referencia Rápida de Solución de Problemas¶

Problema	Primera cosa a verificar	Comando
Los agentes no pueden hacer ping al NGFW (`172.16.0.1`)	VLAN 20 en el trunk del Nexus hacia Ubuntu	`show vlan brief` en Nexus
Error de certificado en los agentes	`ngfw-ca` no instalada o agentes no reiniciados	Repetir el paso 9
Todas las personas devuelven `000`	NGFW no enruta o política TLS bloqueando	Verificar que la política de acceso del NGFW permita `172.16.0.0/16` → `10.1.0.0/16`
Grafana no muestra datos de CPU del NGFW	SNMP no configurado o problema en VLAN 99	`snmpwalk -v2c -c public 192.168.90.3 1.3.6.1.2.1.1.1.0`
Las sesiones HTTP/3 fallan	El NGFW no soporta inspección QUIC	Bloquear UDP 443 en el NGFW para probar solo HTTP/2
Algunas personas fallan, otras funcionan	El NGFW no tiene subinterfaz para esa VLAN	Verificar que el NGFW tiene IP configurada para la VLAN de la persona con falla
Pods atascados en `Pending`	Recursos del nodo agotados	`kubectl describe pod <nombre-del-pod> -n web-agents`
Cloner sin IP en `net1`	DHCP daemon no Ready en el nodo del cloner	`kubectl get ds cni-dhcp-daemon -n web-agents`
Slots atascados en `MountVolume.SetUp failed`	Servidor NFS no Ready o en otro nodo	`kubectl -n web-agents get pod -l app.kubernetes.io/name=nfs-server -o wide`
PVC `cloned-sites` `Pending`	PV estático no vinculado — `volumeName` incorrecto	`kubectl describe pv cloned-sites-writer` y los PVs de los slots
Slots Ready pero sirviendo `404`	Cloner aún no terminó job para ese `personaName`	Revisar tabla `clone_jobs`

Paso 22 — Verificar el stack de almacenamiento del cloner¶

El cloner depende de tres componentes del overlay DUT: el daemon CNI DHCP (para que el IPAM de la VLAN 40 funcione), el servidor NFS in-cluster (para que las escrituras del cloner sean visibles a los slots cross-node) y 11 pares estáticos PV/PVC que vinculan el claim cloned-sites de cada slot al mismo export NFS.

# DHCP daemon — Ready en cada nodo con pod IPAM=dhcp
kubectl get ds cni-dhcp-daemon -n web-agents

# Servidor NFS — réplica única, prefiere role=infra (multi-node) o cualquiera (single)
kubectl get pod -n web-agents -l app.kubernetes.io/name=nfs-server -o wide

# 11 pares PV/PVC — 1 writer RWX + 10 readers ROX, todos Bound
kubectl get pv | grep cloned-sites
kubectl get pvc -A | grep cloned-sites

# Tráfico NFS debe usar SOLO OOBI — el Service no tiene anotación Multus
kubectl get svc nfs-server -n web-agents -o yaml | grep 'k8s.v1.cni.cncf.io' || echo "OK — solo OOBI"

Referencia completa de configuración del NGFW (todas las VLANs, IPs, ejemplos por fabricante): docs/NGFW_CONFIGURATION_REFERENCE.es.md Detalles del instalador automatizado: scripts/k8s-install.sh Visión general de la arquitectura: docs/ARCHITECTURE.md