Teste de Performance NGFW — Checklist de Início Rápido¶

Para quem é este documento: qualquer pessoa que está configurando o TLSStress.Art para rodar um teste de performance de inspeção TLS em um NGFW físico pela primeira vez. Nenhuma experiência prévia com Kubernetes é necessária — cada comando está pronto para ser copiado.

Tempo estimado: ~2 horas (cabeamento + configuração do NGFW + instalação do software)

Autor: André Luiz Gallon — agallon@Cisco.com | Versão: v3.6.0

Status do escopo (pós-congelamento de escopo 2026-05-10) — Ver ARCHITECTURE.md para os 37 MÓDULOs canônicos + 7 Test Kinds + arquitetura de safety DOM/CPOS/PIE-PA. ADRs 0014, 0019-0025 cobrem adições pós-Freeze.

Antes de Começar — O que Você Precisa¶

Hardware¶

1 servidor Ubuntu (host do test-bed) — Ubuntu 22.04 LTS, mínimo 8 núcleos / 32 GB RAM / 100 GB de disco
1 Cisco Nexus 9000 (ou qualquer switch gerenciável com trunking 802.1q)
1 NGFW (o dispositivo sendo testado — Cisco FTD, FortiGate, Palo Alto, Check Point, etc.)
Cabos de rede: 2–3 cabos entre Ubuntu ↔ Nexus; 2 cabos entre Nexus ↔ NGFW

Software (no servidor Ubuntu)¶

Ubuntu 22.04 LTS instalado e acessível via SSH
Acesso sudo no servidor Ubuntu
git instalado: sudo apt-get install -y git

Conhecimento necessário¶

Você sabe acessar um servidor Linux via SSH
Você sabe fazer login na interface web ou CLI do seu NGFW
Você conhece a CA de interceptação do seu NGFW (a CA que ele usa para reassinar certificados HTTPS na inspeção TLS)

Fase 1 — Cabear o Hardware¶

Passo 1 — Conectar o servidor Ubuntu ao Nexus 9000¶

Conecte eth1 no servidor Ubuntu a uma porta trunk no Nexus 9000.

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

eth0 no Ubuntu é para SSH e gerência — NÃO use para tráfego de teste.

Passo 2 — Conectar o NGFW ao Nexus 9000¶

Conecte dois cabos: um para a interface inside do NGFW (lado dos agentes) e um para a outside (lado dos webservers).

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

Opcionalmente conecte um terceiro cabo para gerência SNMP (VLAN 99).

Fase 2 — Configurar o Nexus 9000¶

Passo 3 — Configurar VLANs e portas trunk no Nexus 9000¶

Acesse o Nexus 9000 via SSH ou console e execute:

configure terminal

! Criar todas as VLANs
vlan 20,30,99,101-120
  name test-vlans
exit

! Trunk em direção ao servidor Ubuntu
interface <interface-para-ubuntu>
  switchport mode trunk
  switchport trunk allowed vlan 20,30,99,101-120
  no shutdown
exit

! Trunk em direção ao NGFW inside (agentes)
interface <interface-para-ngfw-inside>
  switchport mode trunk
  switchport trunk allowed vlan 20,30
  no shutdown
exit

! Trunk em direção ao NGFW outside (webservers)
interface <interface-para-ngfw-outside>
  switchport mode trunk
  switchport trunk allowed vlan 101-120
  no shutdown
exit

! Opcional: access port para gerência SNMP do NGFW
interface <interface-para-ngfw-mgmt>
  switchport mode access
  switchport access vlan 99
  no shutdown
exit

copy running-config startup-config

Substitua <interface-para-...> pelos nomes reais das suas interfaces (ex.: Ethernet1/1, Ethernet1/2, Ethernet1/3).

Resultado esperado: show vlan brief mostra as VLANs 20, 30, 99, 101–120 como ativas.

Fase 3 — Instalar o Software no Ubuntu¶

Passo 4 — Clonar o repositório¶

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

Passo 5 — Executar o 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 em eth1 e faz o deploy completo do web agent cluster. Leva aproximadamente 15–20 minutos.

Tem mais de um UCS disponível? Este checklist segue o caminho single-node (um único host Ubuntu roda tudo). Há outros três modos de deployment: - Dual-node (2 UCS) — UCS-1 roda a frota de agentes, UCS-2 roda personas + serviços. Veja UBUNTU_K3S_DUALNODE_QUICKSTART_DEPLOY.pt-BR.md. - Tri-node (3 UCS) — UCS-1 = browser engine, UCS-2 = synthetic-load engine, UCS-3 = personas + serviços. Adiciona isolamento de runtime entre os dois tipos de agente. Veja UBUNTU_K3S_TRINODE_QUICKSTART_DEPLOY.pt-BR.md. - Multi-node (4 UCS) — uma função por UCS, máximo throughput. Veja UBUNTU_K3S_MULTINODE_QUICKSTART_DEPLOY.pt-BR.md.

Todas as alternativas usam k8s-install.sh com flags --mode diferentes. O restante deste checklist (PKI do NGFW, verificação, execução do teste) vale para os quatro modos — só a Fase 3 muda.

Resultado esperado ao final do script:

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

Passo 6 — Verificar se todos os pods estão rodando¶

kubectl get pods -n web-agents

Todos os pods devem aparecer como Running ou Completed. Se algum estiver Pending ou Error, aguarde mais 2 minutos e tente novamente.

kubectl get pods -n web-agents --watch
# Pressione Ctrl+C quando todos os pods mostrarem Running

Passo 7 — Ativar o modo DUT (coloca o NGFW no caminho dos dados)¶

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 — Troca de Certificados PKI (o passo mais importante)¶

Esta fase configura a confiança mútua de certificados entre o cluster e o NGFW. Não pule esta fase.

Passo 8 — Exportar persona-ca do cluster → importar no NGFW¶

Esta CA assina todos os certificados das personas (20 Synthetic + 10 Cloned slots). O NGFW deve confiar nela para validar as conexões TLS do Leg 2.

8a. Exportar a CA do cluster:

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

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

Saída esperada:

subject=O=Web Agent Cluster, OU=DUT Lab, CN=Persona CA
notBefore=<data>
notAfter=<data 10 anos depois>

8b. Copiar o arquivo para seu notebook:

# Do seu notebook (não do servidor):
scp ubuntu@<ip-do-servidor>:/tmp/persona-ca.pem ~/Downloads/persona-ca.pem

8c. Importar no NGFW — use os passos do seu fabricante em docs/NGFW_CONFIGURATION_REFERENCE.pt-BR.md, seção 8. Em geral:

Fabricante	Onde 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` (colar o 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

Passo 9 — Exportar ngfw-ca do NGFW → instalar no cluster¶

Esta é a CA de interceptação própria do NGFW. Os agentes precisam confiar nela para aceitar os certificados reassinados pelo NGFW.

9a. Exportar do NGFW (consulte a seção 6.2 da referência NGFW para o seu fabricante). Salve como ngfw-ca.pem no seu notebook.

9b. Copiar para o servidor Ubuntu:

# Do seu notebook:
scp ~/Downloads/ngfw-ca.pem ubuntu@<ip-do-servidor>:/tmp/ngfw-ca.pem

9c. Instalar no 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 os agentes para carregar a nova CA:

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

# Aguardar o reinício completar
kubectl rollout status deployment/web-agent -n web-agents
kubectl rollout status deployment/k6-agent  -n web-agents

Saída esperada:

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

Fase 5 — Configurar o NGFW¶

Passo 10 — Configurar subinterfaces de VLAN no NGFW¶

Para cada VLAN na tabela abaixo, crie uma subinterface com o endereço IP indicado. Consulte a seção 8 de docs/NGFW_CONFIGURATION_REFERENCE.pt-BR.md para os passos específicos do seu fabricante.

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

Passo 11 — Criar zonas de segurança no NGFW¶

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

Passo 12 — Criar a política de inspeção TLS no NGFW¶

Crie uma política que descriptografa e inspeciona todo o tráfego HTTPS dos agentes para as personas:

Regra	Origem	Destino	Portas	Ação
Inspecionar tudo	`172.16.0.0/16`, `172.17.0.0/16`	`10.1.0.0/16`	TCP 443, UDP 443	Descriptografar e Inspecionar

Use a persona-ca importada no passo 8 como CA confiável para conexões de saída (Leg 2)
Use a CA de interceptação do NGFW (exportada no passo 9) para reassinar certificados para os agentes (Leg 1)

Fase 6 — Verificar se Tudo Funciona¶

Passo 13 — Verificar se o gateway do NGFW é acessível pelos agentes¶

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

# Fazer ping para o gateway do NGFW
ping -c 3 172.16.0.1

Saída esperada:

3 packets transmitted, 3 received, 0% packet loss

Se os pings falharem: verifique se a VLAN 20 está configurada no trunk do Nexus em direção ao Ubuntu e na interface inside do NGFW.

Passo 14 — Verificar se a inspeção TLS está ativa¶

# Ainda dentro do 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 (inspeção TLS funcionando):

issuer=CN=<Nome da CA de interceptação do seu NGFW>
subject=CN=shop.persona.internal

Problema (inspeção TLS NÃO funcionando — NGFW fora do caminho):

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

Se o emissor for Persona CA, o NGFW não está interceptando o tráfego. Verifique: a política TLS do NGFW está ativa, as zonas estão corretas, o tráfego está roteando pelo NGFW.

Problema (erro de certificado):

SSL certificate verify error: unable to get local issuer certificate

Se você ver um erro de certificado, a ngfw-ca não foi instalada ou os agentes não foram reiniciados. Refaça o passo 9.

Passo 15 — Verificar se todas as 20 personas estão acessíveis¶

# Dentro do 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: todas as 20 personas retornam HTTP 200. Qualquer 000 indica que a persona está inacessível (verifique o roteamento do NGFW para aquela VLAN).

Fase 7 — Rodar o Teste e Ler os Resultados¶

Passo 16 — Abrir o dashboard¶

O dashboard roda na porta 3000 do servidor Ubuntu:

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

No dashboard você pode: - Ver quais personas estão ativas (verde = rodando, vermelho = erro) - Iniciar/parar a carga browser engine e synthetic-load engine - Ajustar o número de sessões de agente simultâneas

Passo 17 — Iniciar o teste de carga¶

No dashboard, clique em Start Test ou use a CLI:

# Iniciar agentes browser-engine (simulação 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 as réplicas gradualmente para aumentar a carga.

Passo 18 — Abrir o Grafana para ver as métricas de performance¶

O Grafana roda na porta 3001:

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

Credenciais padrão: admin / admin (altere no primeiro login)

Dashboards principais para monitorar:

Dashboard	O que mostra	O que observar
TLS Throughput	MB/s de tráfego inspecionado	Quedas sob carga = gargalo no NGFW
TLS Latency	ms adicionados por conexão pela inspeção	Picos = CPU do NGFW sofrendo
HTTP/3 vs HTTP/2	Comparação QUIC vs TCP	Taxa de queda QUIC = limite de suporte QUIC do NGFW
Error Rate	% de conexões derrubadas	>1% de erro = NGFW sobrecarregado
NGFW CPU (SNMP)	Utilização de CPU do NGFW	Correlacione CPU% com quedas de throughput

Passo 19 — Interpretar os resultados¶

Métrica	Resultado bom	Atenção	Crítico
TLS Throughput	Estável no alvo	Queda gradual	Queda repentina >20%
Latência TLS adicionada	< 5ms por conexão	5–20ms	> 20ms
Taxa de erro	< 0,1%	0,1–1%	> 1%
CPU do NGFW	< 70%	70–85%	> 85% (throttling)

Os resultados mostram a capacidade máxima de inspeção TLS do NGFW antes de o desempenho degradar.

Limpeza — Parar o Teste¶

Passo 20 — Reduzir os agentes para zero¶

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

Passo 21 — Desativar o modo DUT (opcional)¶

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

Passo 23 — Aplicar tuning de host em CADA nó¶

OBRIGATÓRIO para as stacks Synthetic Persona e Cloned Persona. Sem este tuning os buffers UDP do kernel limitam QUIC a ~30 Mbps por réplica e o cwnd TCP é resetado a cada janela idle de HTTP/2. Também válido pra UCS-2/UCS-3 (frota de agentes) — sem esses sysctls, 1000 réplicas synthetic-load engine esgotam a tabela conntrack e os agentes começam a reportar "TCP connect timeout" aleatórios.

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

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

# Verificar em cada nó (relatório colorido)
sudo scripts/host-tuning.sh status

--enable-cpu-pinning ativa cpuManagerPolicy: static no kubelet e reinicia o kubelet — planejar janela. Não usar nos hosts de agentes (HPA escala 1→300/1000 réplicas, cores exclusivos seriam desperdício). Detalhes em PERFORMANCE_TUNING_HOST.md.

Referência Rápida de Solução de Problemas¶

Problema	Primeira coisa a verificar	Comando
Agentes não conseguem fazer ping para o NGFW (`172.16.0.1`)	VLAN 20 no trunk do Nexus em direção ao Ubuntu	`show vlan brief` no Nexus
Erro de certificado nos agentes	`ngfw-ca` não instalada ou agentes não reiniciados	Refazer o passo 9
Todas as personas retornam `000`	NGFW não roteando ou política TLS bloqueando	Verificar se a política de acesso do NGFW permite `172.16.0.0/16` → `10.1.0.0/16`
Grafana não mostra dados de CPU do NGFW	SNMP não configurado ou problema na VLAN 99	`snmpwalk -v2c -c public 192.168.90.3 1.3.6.1.2.1.1.1.0`
Sessões HTTP/3 falham	NGFW não suporta inspeção QUIC	Bloquear UDP 443 no NGFW para testar apenas HTTP/2
Algumas personas falham, outras funcionam	NGFW sem subinterface para aquela VLAN	Verificar se o NGFW tem IP configurado para a VLAN da persona com falha
Pods travados em `Pending`	Recursos do nó esgotados	`kubectl describe pod <nome-do-pod> -n web-agents`
Cloner sem IP em `net1`	DHCP daemon não Ready no nó do cloner	`kubectl get ds cni-dhcp-daemon -n web-agents`
Slots travados em `MountVolume.SetUp failed`	NFS server não Ready ou em outro nó	`kubectl -n web-agents get pod -l app.kubernetes.io/name=nfs-server -o wide`
PVC `cloned-sites` `Pending`	PV estático não vinculado — `volumeName` errado	`kubectl describe pv cloned-sites-writer` e os PVs dos slots
Slots Ready mas servindo `404`	Cloner ainda não terminou job pra aquele `personaName`	Conferir tabela `clone_jobs`

Passo 22 — Verificar a stack de storage do cloner¶

O cloner depende de três componentes do overlay DUT: o daemon CNI DHCP (pra IPAM da VLAN 40 funcionar), o NFS server in-cluster (pra escritas do cloner ficarem visíveis aos slots cross-node) e 11 pares estáticos PV/PVC que vinculam o claim cloned-sites de cada slot ao mesmo export NFS.

# DHCP daemon — Ready em todo nó com pod IPAM=dhcp
kubectl get ds cni-dhcp-daemon -n web-agents

# NFS server — réplica única, prefere role=infra (multi-node) ou qualquer (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áfego NFS deve usar SOMENTE OOBI — Service não tem anotação Multus
kubectl get svc nfs-server -n web-agents -o yaml | grep 'k8s.v1.cni.cncf.io' || echo "OK — só OOBI"

Referência completa de configuração do NGFW (todas as VLANs, IPs, exemplos por fabricante): docs/NGFW_CONFIGURATION_REFERENCE.pt-BR.md Detalhes do instalador automatizado: scripts/k8s-install.sh Visão geral da arquitetura: docs/ARCHITECTURE.md