Skip to content

Roadmap gNMI — TLSStress.Art

Leia no seu idioma: English · Português · Español

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. Este documento captura o design e a justificativa de decisão para adicionar suporte a gNMI (gRPC Network Management Interface) ao TLSStress.Art. É um documento de roadmap — nenhum código é entregue sob este nome de arquivo no repositório hoje. Quando a implementação chegar, este documento será atualizado com os caminhos reais e a orientação do operador.

Público-alvo: operadores, parceiros, clientes e stakeholders do Cisco Legal que perguntam "vocês suportam gNMI?" e precisam de uma resposta definitiva. A resposta hoje é sim, no roadmap, com um plano deliberadamente faseado; não, ainda não rodando em produção.

O que é gNMI

gNMI é um protocolo de gerenciamento de rede desenvolvido pelo consórcio OpenConfig (Google + grandes vendors de rede). É o sucessor moderno do SNMP para telemetria em streaming e gerenciamento de configuração.

Características principais:

Aspecto Valor
Transporte gRPC sobre HTTP/2, TLS obrigatório
Autenticação Certificados TLS (mTLS preferido) ou usuário/senha
Modelo de dados Definido em YANG, neutro entre vendors via OpenConfig
Operações Get, Set, Subscribe, Capabilities
Modos de subscription STREAM SAMPLE (push periódico), STREAM ON_CHANGE (push em mudança de valor), POLL, ONCE
Encodings JSON-IETF, PROTO, JSON, BYTES

Por que gNMI importa para o TLSStress.Art

Aspecto SNMP (hoje) gNMI (futuro)
Transporte UDP (lossy, sem integridade de auth) gRPC + TLS (confiável, criptografado, autenticado)
Modelo de polling Cliente faz polling a cada intervalo Servidor faz streaming para o cliente
Latência Intervalos de polling de 30–60 s típicos STREAM SAMPLE sub-segundo
Eficiência de banda Polls completos repetidos Apenas deltas via ON_CHANGE
Schema MIBs (específicas de vendor, frequentemente desatualizadas) YANG OpenConfig (neutro entre vendors)
Auth Community strings (fraco) mTLS + validação de certificado
Carga de polling no Cisco Nexus 5–10% de CPU no switch <1% de CPU

Suporte de vendors — matriz honesta da realidade

Uma percepção comum equivocada é que "todos os dispositivos modernos suportam gNMI". A verdade é mais matizada. Em 2026:

Vendor / Dispositivo gNMI nativo? Notas de cobertura
Cisco Nexus 9000 (NX-OS 9.2+) ✅ Sim OpenConfig parcial + YANG específico da Cisco; feature grpc para habilitar
Cisco IOS-XR / IOS-XE ✅ Sim Roteadores — fora do escopo do test-bed hoje, mas suportados
Juniper Junos ✅ Sim Forte cobertura OpenConfig
Arista EOS ✅ Sim Nativo, OpenConfig completo + extensões EOS
Cisco FTD / Firepower (cdFMC ou on-prem FMC managed) ✅ Sim OpenConfig streaming telemetry via gNMI é suportado nativamente quando o FTD é gerenciado por Cloud-Delivered FMC (cdFMC) ou on-prem FMC. Ativado via FTD health policy. O FTD abre um servidor gNMI em TCP 50051 (modo DIAL-IN) OU estabelece um túnel gRPC de saída para um collector (modo DIAL-OUT). Modos de Subscribe: Once, Sampled (intervalo ≥1-min), On-change. Autenticação mTLS obrigatória. Referência: https://docs.manage.security.cisco.com/cdfmc/c_openconfig_streaming_telemetry.html
Cisco FTD / Firepower (FDM-managed standalone) ⚠️ Indireto A implantação standalone somente FDM que o adapter REST do TLSStress.Art (PR #198) endereça hoje usa a FDM REST API. gNMI é exposto via plano de gerenciamento cdFMC / on-prem FMC, não diretamente através do FDM.
Cisco UCS Manager ❌ Não XML API + Redfish; gNMI não está no roadmap UCS da Cisco
Cisco UCS C-series CIMC ❌ Não Apenas Redfish
Palo Alto PAN-OS ⚠️ Limitado API primária é XML/REST; exposição de gNMI é parcial e indocumentada para métricas centrais de decryption
Fortinet FortiGate (FortiOS 7.0+) ⚠️ Parcial gRPC streaming para campos selecionados de monitoramento; sem conformidade total com gNMI para configuração

Implicação para o TLSStress.Art: gNMI é um complemento à stack existente de REST API + SNMP + syslog. Genuinamente transformador para o tier de switches (Cisco Nexus + futuro suporte a Juniper/Arista) E para o Cisco FTD gerenciado por cdFMC / FMC (streaming sub-minuto de estado operacional, eventos on-change para flaps de interface). Não adiciona nada para saúde de hardware UCS — UCS não fala gNMI — e o FTD standalone gerenciado por FDM que nosso adapter REST endereça hoje continua dependendo do FDM REST.

Para operadores em cdFMC, a integração gNMI torna-se o pilar de menor latência para telemetria operacional do FTD — muito à frente de esperar polls de SNMP ou snapshots REST.

Onde gNMI se encaixa na arquitetura de pilares existente

A stack atual de telemetria do TLSStress.Art tem 4 pilares:

1. Metrics (numerical)         SNMP, node-exporter, kubelet
2. Events (reactive)           Syslog → Loki
3. API (config + state)        FTD / Nexus / UCS / Fortinet REST adapters (PR #198/#199/#200/#201)
4. Probes (independent)        TLS Decrypt Mode Probe (issuer cert detection)

gNMI se torna o 5º pilar:

5. Streaming telemetry         gNMI subscribe streams from compliant switches
                               (sub-second SAMPLE; ON_CHANGE for state transitions)

Criticamente, nenhum dos pilares existentes é removido. SNMP permanece para contadores de UCS + NGFW. Syslog permanece para eventos. REST API permanece para configuração + estado de decrypt-policy em NGFW + saúde de hardware UCS.

O que ganhamos ao adicionar gNMI

Capacidade Sem gNMI (hoje) Com gNMI
Contadores por interface (Nexus) SNMP ifTable consultado a cada 30–60 s STREAM SAMPLE sub-segundo
Profundidade de fila + drops (QoS Nexus) SNMP, frequentemente ausente para features de ASIC mais novos Modelo OpenConfig qos:queues
Níveis ópticos em transceivers SNMP entSensorTable parcial OpenConfig terminal-device:optical-channel
Utilização de TCAM (filter NGFW, ACL Nexus) SNMP parcial, específico de vendor OpenConfig + YANG Cisco, sub-segundo
Transições de estado (interface up/down) Polled na cadência SNMP — perde flaps <1 s STREAM ON_CHANGE captura cada transição
Suporte multi-vendor a switches Mapeamento MIB por vendor no código Os mesmos paths de Subscribe funcionam em Cisco/Juniper/Arista

A vitória de destaque: quando uma porta Nexus dá flap por 800 ms durante uma execução, SNMP perde; gNMI captura. Esta é a diferença entre "spike de p99 sem causa aparente" e "spike de p99 correlacionado com flap de porta às 14:32:01.812".

O que NÃO ganhamos

Para ser preciso sobre o escopo:

  • ❌ Estado de decrypt policy do NGFW — nenhum modelo OpenConfig YANG existe para regras de decrypt específicas de vendor
  • ❌ Térmica / energia / ECC de DIMM do UCS — UCS não fala gNMI
  • ❌ Semântica de deploy state do FTD (a noção "DEPLOYED / PENDING" do FDM) — apenas FDM REST
  • ❌ Substituição de SNMP no UCS — UCS depende de SNMP/Redfish para hardware

O que NÓS ganhamos no FTD gerenciado por cdFMC (correção em relação ao rascunho anterior):

  • ✅ Contadores de interface (bytes, errors, drops por porta) em cadência ≥1-min
  • ✅ Notificações ON_CHANGE para transições de estado de interface
  • ✅ Modelos OpenConfig em nível de sistema (CPU, memória, processos)
  • ✅ Consistência de queries multi-vendor — o mesmo path Subscribe funciona em Cisco FTD + Cisco Nexus + Juniper + Arista quando esses forem adicionados

Se você lê marketing alegando que "gNMI substitui tudo", essa alegação continua errada — mas para usuários de cdFMC ela substitui um subconjunto significativo do que atualmente coletamos via REST + SNMP.

Três opções arquiteturais (com trade-offs)

Opção A — Cliente gNMI nativo dentro do pod do dashboard (Node.js)

Implementar o cliente gNMI em TypeScript dentro do processo do dashboard Next.js.

Pro Con
Zero novos containers Bibliotecas gNMI no ecossistema Node são imaturas (os melhores clients são Go + Python)
Único deployment Subscriptions gRPC de longa duração dentro do processo Next.js arriscam problemas de memória
Reutiliza Postgres + auth de admin existentes Lógica de gRPC keepalive + reconnect em JS é frágil

Veredito: 🚫 Não recomendado.

Opção B — Microsserviço Go dedicado

Construir um pequeno serviço Go (~500 LoC) usando github.com/openconfig/gnmi. Lê a lista de dispositivos de uma tabela Postgres dut_gnmi_devices, estabelece streams Subscribe, traduz updates em métricas Prometheus OU escreve em uma tabela dut_gnmi_samples.

Pro Con
Go tem bibliotecas gNMI maduras Nova imagem de container — incha o bundle de air-gap
Tratamento nativo de gRPC + HTTP/2 + TLS Nova linguagem para o time manter
Subscriptions de longa duração são o ponto forte de Go Superfície de deployment mais complexa
Separa domínio de falha do dashboard

Veredito: ✅ Resposta certa quando gNMI é uma prioridade de produto (não apenas exploração).

Opção C — Sidecar gnmic (recomendado para a primeira iteração)

gnmic é a ferramenta CLI open-source que é o cliente gNMI de facto em observabilidade de rede. Rode-o como um Deployment Kubernetes com configuração via ConfigMap. Tem saída embutida para Prometheus exporter, Loki, InfluxDB, NATS.

Pro Con
Zero código gNMI que mantemos — gnmic é maduro, open-source Dois sistemas de configuração (REST API em Postgres, gNMI em ConfigMap YAML)
Modo Prometheus exporter nativo encaixa na nossa stack Menos controle sobre o formato dos dados
~2 dias de trabalho de operador + ops, sem código novo Imagem gnmic para empacotar em air-gap
Valida o caso de uso rapidamente com baixo investimento Operador gerencia configuração do gnmic separadamente da configuração do dashboard

Veredito: ✅ Recomendado para a Fase 1.

Plano faseado

Fase 0 — Este documento (AGORA)

  • ✅ Documento de roadmap publicado em 3 idiomas
  • ✅ Matriz honesta de suporte de vendors
  • ✅ Opções arquiteturais analisadas
  • ✅ Justificativa de decisão documentada para futuros operadores / clientes / Cisco Legal

Nenhum código entregue. Esta fase é sobre conhecimento institucional — quando alguém pergunta "vocês suportam gNMI?", apontamos para este documento.

Fase 1 — Sidecar gnmic (após validação em produção do v1.0)

Trigger: TLSStress.Art foi implantado em pelo menos um lab real, a telemetria existente de 4 pilares foi validada de ponta a ponta, e há demanda do operador por telemetria de switch sub-segundo.

Escopo (~2 dias de trabalho): 1. k8s/optional/gnmic-sidecar.yaml — Deployment + ConfigMap com configuração gnmic 2. Paths de subscription gNMI por dispositivo Nexus (interfaces, qos, system) 3. Modo Prometheus exporter emitindo séries sob namespace tlsstress_gnmi_* 4. Dashboard Grafana "TLSStress.Art — Nexus Sub-Second Telemetry" lendo dessas métricas 5. docs/GNMI_OPERATIONS.{md,pt-BR.md,es.md} — guia do operador para habilitar feature grpc no Nexus + registrar paths na configuração do gnmic

Fora de escopo na Fase 1: - Suporte multi-vendor (apenas Cisco Nexus inicialmente) - Operações Set (apenas leitura) - Integração Loki para ON_CHANGE (Fase 2) - Metadados gNMI nas tabelas de snapshots da DUT API (Fase 2)

Fase 2 — Microsserviço Go dedicado (v2.0)

Trigger: Fase 1 provou o caso de uso gNMI em pelo menos um lab real E há demanda por (a) operações de escrita, (b) mais vendors, ou (c) integração mais profunda com o fluxo existente de snapshot / report.

Escopo (~1–2 semanas de trabalho): 1. services/gnmi-collector/ — microsserviço Go, ~500-1000 LoC 2. Tabela dut_gnmi_devices — registra dispositivos que falam gNMI (auth baseada em cert) 3. Tabela dut_gnmi_samples — armazenamento de longo prazo para amostras de alto valor 4. Integração Loki para eventos ON_CHANGE 5. Suporte multi-vendor: Cisco Nexus + Juniper Junos + Arista EOS 6. Anexo E "evidência de streaming gNMI" do Test Run Report com timing sub-segundo ao lado da janela da execução 7. Suporte opcional a operação Set com o mesmo fluxo de confirmação do operador usado para escritas via REST API

Fase 3 — Substituir o sidecar gnmic pelo serviço Go (v2.x)

Se a Fase 2 entregar e for estável, o sidecar gnmic torna-se redundante. Aposentamos. Operadores com deployments da Fase 1 são migrados implantando o serviço Go ao lado, executando em paralelo por uma release, então desligando o gnmic.

Por que NÃO estamos entregando a Fase 1 nesta iteração

Raciocínio honesto:

  1. PRs existentes na fila precisam aterrissar primeiro — adicionar gNMI sobre uma fila não estabilizada agrava a complexidade de merge
  2. Nenhum teste end-to-end em hardware real ainda — adicionar mais pilares de telemetria antes de validar os existentes é otimização prematura
  3. gNMI ajuda predominantemente switches — temos um switch (Cisco Nexus). 1 hora de configuração gnmic eventualmente nos dará o que precisamos, sem novo microsserviço
  4. Spirent / Ixia também não têm gNMI — adicioná-lo nos posiciona para o futuro, mas não nos coloca "à frente" dos competidores hoje; já estamos à frente via padrão de adapter multi-vendor
  5. Complexidade para o operador — cada novo pilar = mais um dashboard que o operador precisa aprender. Até que os dashboards existentes provem seu valor em produção, adicionar mais é overhead

A jogada "à frente dos competidores" neste momento é operacionalizar o que temos: pre-flight checks (PR-C), wiring da Fase 3 do Test Run Report (PR-D), validação em lab real. Não adicionar mais fontes de telemetria.

Quando ENTREGAREMOS a Fase 1

Condições de trigger, todas as quais devem ser verdadeiras:

  • Pelo menos um deployment em lab real com os 4 pilares existentes exercitando end-to-end
  • Test Run Report Fase 3 (Anexos B/C/D) entregue e validado
  • PR-C (pre-flight checks) entregue e exercitado em uma execução real
  • Um operador pediu explicitamente por telemetria de switch sub-segundo
  • Cisco Nexus 9000 está em um lab de cliente + temos credenciais

Quando as quatro caixas estiverem marcadas, a Fase 1 é ~2 dias de trabalho.

Comparação de capacidades vs alternativas comerciais

Feature Spirent CyberFlood Ixia BreakingPoint TLSStress.Art (com Fase 1 gNMI)
Suporte a subscription gNMI ❌ ❌ ✅ (Cisco Nexus inicialmente)
Modelos YANG OpenConfig ❌ ❌ ✅
Switch multi-vendor via gNMI ❌ ❌ ✅ (Fase 2)
Telemetria de porta sub-segundo ⚠️ derivada de SNMP, presa ao vendor ⚠️ presa ao vendor ✅
Arquitetura aberta ❌ ❌ ✅

O diferencial estrutural é a arquitetura aberta multi-vendor. gNMI a reforça; não é a fonte dela.

Referências

Relacionados