Nexus 9000 — Tuning para TLSStress.Art (DUT Mode)¶

Audiência: engenheiro de redes responsável pelo Cisco Nexus 9000 que conecta os servidores K8s ao NGFW em teste. Versão: v3.3.0

Scope status (post-Scope-Freeze 2026-05-10) — See ARCHITECTURE.md for the canonical 37 MÓDULOs + 7 Test Kinds + DOM/CPOS/PIE-PA safety architecture. ADRs 0014, 0019-0025 cover post-Freeze additions. Pré-requisito: DUT mode K8s overlay aplicado — k8s/dut/

Visão geral da topologia¶

┌─────────────┐   VLAN 20 (172.16.0.0/16)    ┌──────────────┐
│  K8s Agents │ ──────────────────────────── │              │
│ (browser engine)│         UDP 443 (QUIC)        │   Cisco      │
│   (k6)      │   VLAN 30 (172.17.0.0/16)    │  Nexus 9000  │
└─────────────┘         TCP 443 (HTTP/2)      │              │
                                              │  Este guia   │
┌─────────────┐   VLANs 101-120              │              │
│  K8s Caddy  │   (10.1.{1..20}.0/27)        │              │
│ Synthetic   │ ──────────────────────────── │              │
│ Personas    │         UDP 443 (QUIC)        └──────┬───────┘
│ (20 pods)   │         TCP 443 (HTTP/2)             │
└─────────────┘                               ┌──────┴───────┐
                                              │     NGFW     │
┌─────────────┐   VLANs 200-209              │  (em teste)  │
│  K8s Caddy  │   (10.2.{1..10}.0/27)        └──────────────┘
│ Cloned      │ ─────── (via NGFW) ─────────►
│ Personas    │
│ (10 slots)  │
└─────────────┘

O Nexus 9000 transporta dois tipos de tráfego críticos: - HTTP/2 sobre TCP 443 — fluxo orientado a conexão, sensível a flow control - HTTP/3 sobre UDP 443 (QUIC) — datagrams, sensível a drops e deprioritização de UDP

Scripts disponíveis¶

Script	Função
`scripts/nexus/01-apply-tuning.nxos`	Aplica todas as configurações de tuning
`scripts/nexus/02-verify.nxos`	Verifica se cada configuração foi aplicada corretamente
`scripts/nexus/03-rollback.nxos`	Reverte todas as alterações para os padrões NX-OS

Procedimento de aplicação¶

Passo 1 — Levantar o baseline¶

Antes de qualquer mudança, salvar o estado atual:

# No switch — salvar running-config como backup
copy running-config bootflash:backup-pre-dut-tuning.cfg

# Anotar estado atual das interfaces críticas
show interface Ethernet<SERVER> | include "MTU|flow|EEE"
show ip load-sharing
show running-config interface Vlan20
show running-config interface Vlan30

Passo 2 — Preencher os placeholders¶

Abrir scripts/nexus/01-apply-tuning.nxos e substituir:

Placeholder	Valor real	Exemplo
`<<SERVER1>>`	Interface do servidor K8s (webservers/personas)	`Ethernet1/1`
`<<SERVER2>>`	Segunda interface server (se houver)	`Ethernet1/2`
`<<AGENT1>>`	Interface do servidor K8s (agentes)	`Ethernet1/3`
`<<AGENT2>>`	Segunda interface agent (se houver)	`Ethernet1/4`
`<<NGFW_IN>>`	NGFW — lado interno (agentes, VLANs 20/30)	`Ethernet1/5`
`<<NGFW_OUT>>`	NGFW — lado externo (personas, VLANs 101-120, 200-209)	`Ethernet1/6`
`<<UPLINK1>>`	Uplink para spine/core	`Ethernet1/47`
`<<VLAN_WEB>>`	VLAN dos webservers (Synthetic Personas, ex: VLAN 101)	`101`
`<<VLAN_AGT>>`	VLAN dos agentes browser engine	`20`

Dica: use show cdp neighbors e show lldp neighbors para confirmar qual interface conecta a qual equipamento.

Passo 3 — Verificar suporte a jumbo frames no NGFW¶

Antes de aplicar MTU 9216, confirmar que o NGFW suporta jumbo no path de inspeção:

! No switch — ping com pacote grande e DF-bit
ping <IP-webserver> df-bit packet-size 8972 count 5

5 replies recebidos → NGFW suporta jumbo → manter seção MTU
Falha → NGFW não suporta jumbo → comentar/remover Seção 1 do script

Passo 4 — Aplicar o script¶

Via TFTP (recomendado para produção):

! Copiar script para servidor TFTP e aplicar:
copy tftp://<ip-tftp>/01-apply-tuning.nxos running-config

Via SCP:

copy scp://<usuario>@<ip-servidor>/scripts/nexus/01-apply-tuning.nxos running-config

Via terminal (colar diretamente):

configure terminal
! <colar conteúdo do script aqui>
end
copy running-config startup-config

Passo 5 — Verificar¶

! Executar comandos do script de verificação:
show running-config | include jumbomtu
show ip load-sharing
show policy-map interface Ethernet<SERVER> type qos input
show running-config interface Vlan20 | include arp

Ou carregar o script completo de verificação:

! Copiar e executar 02-verify.nxos (modo enable, não configure terminal)

Passo 6 — Salvar configuração¶

copy running-config startup-config

Detalhamento de cada configuração¶

1. Jumbo MTU (9216 bytes)¶

Problema: QUIC usa Path MTU Discovery (PMTUD). Com MTU 1500 na fabric, o quic-go limita os datagramas a ~1200 bytes para evitar fragmentação IP. Com MTU 9216, datagramas crescem para ~8800 bytes — menos overhead por byte útil e maior throughput por fluxo.

Impacto medido: em links de 10GbE, MTU 9216 vs 1500 reduz o overhead de headers UDP+IP de ~6% para ~0,7% por byte de payload.

Comandos:

system jumbomtu 9216
interface Ethernet1/X
  mtu 9216

Verificação:

show interface Ethernet1/X | include MTU
! >> MTU 9216 bytes

Cuidado: system jumbomtu altera o MTU padrão de novas interfaces mas não retroage nas já configuradas. Sempre configurar explicitamente por interface.

2. Energy Efficient Ethernet (EEE) — desabilitar¶

Problema: EEE (IEEE 802.3az) reduz o consumo de energia colocando o transceiver em low-power mode quando o link está idle. Ao receber tráfego após período idle, o link precisa de 50–300 µs para "acordar" (Link Partner Response time). Durante esse tempo os primeiros pacotes são descartados.

Impacto em benchmark TLS: handshakes TLS ocorrem em janelas curtas entre sessões. EEE causa jitter visível no p99 de latência de handshake.

Impacto medido: elimina spikes de 50–300 µs no p99 após períodos idle entre testes.

Comandos:

interface Ethernet1/X
  no power efficient-ethernet

Verificação:

show running-config interface Ethernet1/X | include power
! >> no power efficient-ethernet

3. Flow Control — desabilitar¶

Problema: PAUSE frames (IEEE 802.3x) implementam backpressure — quando o buffer de recepção enche, o receptor envia PAUSE e o transmissor para de enviar por pause_time slots de tempo. Isso é global para todos os fluxos no link, não por fluxo individual.

Resultado em benchmark: um fluxo HTTP/2 lento pode enviar PAUSE e pausar fluxos HTTP/3 concorrentes no mesmo link — o benchmark mede o efeito de HOL blocking, não a performance do NGFW.

Comandos:

interface Ethernet1/X
  flowcontrol receive off
  flowcontrol send off

Verificação:

show interface Ethernet1/X | include flow
! >> Receive FlowControl: off, Send FlowControl: off

4. QoS — DSCP AF41 para TCP/UDP 443¶

Problema: o scheduler padrão do Nexus 9000 não diferencia TCP de UDP no enfileiramento. Dependendo da política QoS global do ambiente, UDP pode ser mapeado para filas de menor prioridade. Em benchmark comparativo HTTP/2 vs HTTP/3, isso cria desvantagem artificial para QUIC.

Solução: marcar TCP 443 e UDP 443 com DSCP AF41 (Assured Forwarding 41) na entrada. AF41 garante mesma classe de serviço para ambos os protocolos.

Comandos:

ip access-list BENCH_TLS
  10 permit tcp any any eq 443
  20 permit tcp any eq 443 any
  30 permit udp any any eq 443
  40 permit udp any eq 443 any

class-map type qos match-any BENCH_CLASS
  match access-group name BENCH_TLS

policy-map type qos BENCH_QOS_IN
  class BENCH_CLASS
    set dscp af41

interface Ethernet1/X
  service-policy type qos input BENCH_QOS_IN

Verificação:

show policy-map interface Ethernet1/X type qos input
! >> BENCH_QOS_IN aplicada; contadores crescendo durante tráfego

Verificação de DSCP com ethanalyzer:

ethanalyzer local interface inband display-filter "ip.dscp == 34" limit-captured-frames 10
! >> DSCP 34 = AF41 (0x22) — deve aparecer para TCP e UDP 443

5. ECMP Hash com porta UDP¶

Problema: o hash ECMP padrão do Nexus 9000 considera src IP + dst IP + protocolo. Para fluxos QUIC de um mesmo host (mesmo src IP), todos os fluxos QUIC vão para o mesmo uplink — não há distribuição de carga, independente do número de uplinks disponíveis.

Solução: incluir src port + dst port no hash. Cada fluxo QUIC usa porta de origem aleatória (ephemeral), o que distribui os fluxos uniformemente entre os uplinks.

Impacto: ambientes com 2+ uplinks ou port-channel passam a distribuir carga real por fluxo QUIC.

Comandos:

ip load-sharing address source-destination port source-destination
port-channel load-balance src-dst ip-l4port

Verificação:

show ip load-sharing
! >> address source-destination port source-destination

6. ARP Timeout — 300s¶

Problema: pods com macvlan mudam de IP e MAC ao reiniciar. O ARP timeout padrão do NX-OS é 1500s (~25 minutos). Durante esse período o cache ARP aponta para o MAC antigo (inexistente) e todo o tráfego destinado ao pod vai para um blackhole.

Solução: reduzir para 300s. A janela de blackhole cai de 25 min para 5 min.

Ação manual para convergência imediata após restart de pod:

! Para agentes (VLANs 20/30):
clear ip arp vlan 20
clear ip arp vlan 30
! Para personas sintéticas (VLANs 101-120):
clear ip arp vlan 101
! ... repita para VLANs 102-120 conforme necessário
! Para personas clonadas (VLANs 200-209):
clear ip arp vlan 200
! ... repita para VLANs 201-209 conforme necessário

Comandos (ajustar ARP timeout em todas as VLANs de dados):

interface Vlan20
  ip arp timeout 300
interface Vlan30
  ip arp timeout 300
! Repetir para VLANs 101-120 (Synthetic Personas) e 200-209 (Cloned Personas)

7. Spanning Tree — port type edge¶

Problema: sem spanning-tree port type edge, ao subir uma interface server-facing, o STP coloca a porta em estado listening por 15s, depois learning por 15s, antes de forwarding (~30s total no padrão 802.1D). Durante esse período os pods não têm acesso à rede — parece falha de deploy mas é STP.

bpduguard: se um BPDU chegar nessa porta (outro switch conectado por engano), a porta vai para err-disabled imediatamente — proteção contra loops.

Comandos:

interface Ethernet1/X
  spanning-tree port type edge
  spanning-tree bpduguard enable

Verificação:

show spanning-tree interface Ethernet1/X detail | include Edge
! >> Edge port (PortFast Edge) configured, used

Recuperar porta em err-disabled após bpduguard:

interface Ethernet1/X
  shutdown
  no shutdown
! (após remover o switch indevido da porta)

8. Storm Control — relaxar para QUIC bursts¶

Problema: bursts de QUIC geram muitos datagramas UDP pequenos em rajada curta. Storm control com thresholds conservadores pode throttlear esses bursts, degradando a performance HTTP/3 artificialmente.

Solução: manter proteção broadcast/multicast (legítima), remover unicast storm control. Em benchmark, unicast storm control cria throttling espúrio de QUIC.

Comandos:

interface Ethernet1/X
  storm-control broadcast level 10.00
  storm-control multicast level 10.00
! Não configurar: storm-control unicast level (remove proteção unicast)

Prioridade de aplicação¶

#	Configuração	Impacto	Requer reload?	Script — seção
🔴 1	EEE desabilitado	Elimina jitter de handshake 50–300 µs	Não	Seção 2
🔴 2	ECMP hash com porta UDP	QUIC distribui carga entre uplinks	Não	Seção 5
🔴 3	Flow control off	Elimina HOL blocking entre HTTP/2 e HTTP/3	Não	Seção 3
🟠 4	QoS DSCP AF41 TCP+UDP 443	HTTP/3 não é desprioritizado	Não	Seção 4
🟠 5	MTU 9216 (se NGFW suportar)	Reduz overhead QUIC por datagrama	Não¹	Seção 1
🟠 6	ARP timeout 300s	Pods reiniciam sem blackhole de 25 min	Não	Seção 6
🟡 7	STP port type edge	Deploy sem espera STP de 30s	Não	Seção 7
🟡 8	Storm control relaxado	Evita throttle espúrio em bursts QUIC	Não	Seção 8

¹ system jumbomtu pode requerer reload em alguns modelos N9K. Verificar show system jumbomtu após aplicar.

Troubleshooting¶

QUIC com alta taxa de retransmissão no benchmark¶

! Verificar drops no switch:
show interface Ethernet<SERVER> counters errors
show interface Ethernet<NGFW_IN> counters errors
! >> Se output drops > 0: congestionamento no switch — verificar utilização
show interface Ethernet<SERVER> | include "rate|Rate"

! Verificar UDP socket overflow no host (kernel drops antes do Go):
! No servidor K8s:
! cat /proc/net/udp | awk 'NR>1 {print $5}' | sort | uniq -c
! netstat -su | grep "packet receive errors"
! >> Se não zero: aumentar rmem_max no DaemonSet 85-node-tuning.yaml

QUIC não está distribuindo carga nos uplinks¶

show ip load-sharing
! >> Deve conter "port source-destination"
! Se não contiver: reaplicar Seção 5 do script

! Testar distribuição:
show ip load-sharing forwarding ethernet<UPLINK1> destination <IP-dest> source <IP-src>
! Executar com diferentes portas de origem e verificar se escolhe uplinks diferentes

Pod inacessível após restart (blackhole ARP)¶

! Limpar cache ARP — agentes:
clear ip arp vlan 20
clear ip arp vlan 30
! Limpar cache ARP — Synthetic Persona (substituir 101 pela VLAN do pod):
clear ip arp vlan 101
! Limpar cache ARP — Cloned Persona (substituir 200 pela VLAN do slot):
clear ip arp vlan 200

! Verificar que o novo MAC foi aprendido:
show mac address-table vlan 101 | include <IP-ou-MAC-do-pod>
show ip arp vlan 101

MTU 9216 causando fragmentação ou drops¶

! Teste de MTU end-to-end com DF-bit:
ping <IP-webserver> df-bit packet-size 8972 count 5
! Se falhar: NGFW não suporta jumbo — reverter MTU com 03-rollback.nxos seção R1

! Verificar MTU negociada nos pods (dentro do container):
! ip link show net1
! >> mtu 9216 (se macvlan herdou do parent interface)

Porta em err-disabled após bpduguard¶

show interface Ethernet<X> | include err-disabled
! Se err-disabled: outro switch foi conectado por engano — remover e:
interface Ethernet<X>
  shutdown
  no shutdown

Reverter tudo¶

! Carregar script de rollback:
copy tftp://<ip-tftp>/03-rollback.nxos running-config

! Ou restaurar o backup tirado antes do tuning:
copy bootflash:backup-pre-dut-tuning.cfg running-config

Referências¶

NX-OS QoS Configuration Guide — Cisco Nexus 9000
NX-OS Layer 2 Switching Configuration Guide — Spanning Tree
QUIC Protocol — RFC 9000
quic-go — UDP receive buffer recommendations
DUT mode K8s overlay — manifests aplicados nos pods Caddy e agentes
Node tuning DaemonSet — sysctls UDP/TCP no host Ubuntu