Skip to content

Roadmap gNMI — TLSStress.Art

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. Este documento captura el diseño y la justificación de las decisiones para añadir soporte de gNMI (gRPC Network Management Interface) a TLSStress.Art. Es un documento de roadmap — hoy no se entrega ningún código bajo este nombre de archivo en el repositorio. Cuando aterrice la implementación, este documento se actualizará con las rutas reales y la guía para el operador.

Audiencia: operadores, partners, clientes y stakeholders de Cisco Legal que preguntan "¿soportan gNMI?" y necesitan una respuesta definitiva. La respuesta hoy es sí, en el roadmap, con un plan deliberadamente por fases; no, todavía no en producción.

Qué es gNMI

gNMI es un protocolo de gestión de red desarrollado por el consorcio OpenConfig (Google + grandes vendors de redes). Es el sucesor moderno de SNMP para telemetría en streaming y gestión de configuración.

Características clave:

Aspecto Valor
Transporte gRPC sobre HTTP/2, TLS obligatorio
Autenticación Certificados TLS (mTLS preferido) o usuario/contraseña
Modelo de datos Definido por YANG, neutral respecto al vendor vía OpenConfig
Operaciones Get, Set, Subscribe, Capabilities
Modos de subscription STREAM SAMPLE (push periódico), STREAM ON_CHANGE (push al cambiar el valor), POLL, ONCE
Encodings JSON-IETF, PROTO, JSON, BYTES

Por qué gNMI importa para TLSStress.Art

Aspecto SNMP (hoy) gNMI (futuro)
Transporte UDP (con pérdidas, sin integridad de auth) gRPC + TLS (fiable, cifrado, autenticado)
Modelo de polling El cliente hace polling cada intervalo El servidor hace streaming al cliente
Latencia Intervalos de polling de 30–60 s típicos STREAM SAMPLE sub-segundo
Eficiencia de ancho de banda Polls completos repetidos Solo deltas vía ON_CHANGE
Schema MIBs (específicas de vendor, frecuentemente desactualizadas) YANG OpenConfig (neutral respecto al vendor)
Auth Community strings (débil) mTLS + validación de certificado
Carga de polling en Cisco Nexus 5–10% de CPU en el switch <1% de CPU

Soporte de vendors — matriz honesta de la realidad

Una percepción errónea común es que "todos los dispositivos modernos soportan gNMI". La verdad es más matizada. A fecha de 2026:

Vendor / Dispositivo gNMI nativo? Notas de cobertura
Cisco Nexus 9000 (NX-OS 9.2+) ✅ Sí OpenConfig parcial + YANG específico de Cisco; feature grpc para habilitar
Cisco IOS-XR / IOS-XE ✅ Sí Routers — fuera del alcance del test-bed hoy, pero soportados
Juniper Junos ✅ Sí Cobertura OpenConfig sólida
Arista EOS ✅ Sí Nativo, OpenConfig completo + extensiones EOS
Cisco FTD / Firepower (cdFMC u on-prem FMC managed) ✅ Sí OpenConfig streaming telemetry vía gNMI está soportado nativamente cuando el FTD es gestionado por Cloud-Delivered FMC (cdFMC) u on-prem FMC. Activado vía FTD health policy. El FTD abre un servidor gNMI en TCP 50051 (modo DIAL-IN) O establece un túnel gRPC saliente hacia un collector (modo DIAL-OUT). Modos de Subscribe: Once, Sampled (intervalo ≥1-min), On-change. Autenticación mTLS obligatoria. Referencia: https://docs.manage.security.cisco.com/cdfmc/c_openconfig_streaming_telemetry.html
Cisco FTD / Firepower (FDM-managed standalone) ⚠️ Indirecto El despliegue standalone solo-FDM al que el adapter REST de TLSStress.Art (PR #198) apunta hoy usa la FDM REST API. gNMI se expone vía el plano de gestión cdFMC / on-prem FMC, no directamente a través de FDM.
Cisco UCS Manager ❌ No XML API + Redfish; gNMI no está en el roadmap UCS de Cisco
Cisco UCS C-series CIMC ❌ No Solo Redfish
Palo Alto PAN-OS ⚠️ Limitado API primaria es XML/REST; la exposición de gNMI es parcial e indocumentada para métricas centrales de decryption
Fortinet FortiGate (FortiOS 7.0+) ⚠️ Parcial gRPC streaming para campos selectos de monitoreo; sin conformidad total con gNMI para configuración

Implicación para TLSStress.Art: gNMI es un complemento al stack existente de REST API + SNMP + syslog. Genuinamente transformador para el tier de switches (Cisco Nexus + futuro soporte de Juniper/Arista) Y para el Cisco FTD gestionado por cdFMC / FMC (streaming sub-minuto del estado operacional, eventos on-change para flaps de interfaz). No aporta nada para la salud de hardware UCS — UCS no habla gNMI — y el FTD standalone gestionado por FDM al que apunta hoy nuestro adapter REST sigue dependiendo de FDM REST.

Para operadores en cdFMC, la integración gNMI se convierte en el pilar de menor latencia para la telemetría operacional del FTD — muy por delante de esperar polls de SNMP o snapshots REST.

Dónde encaja gNMI en la arquitectura de pilares existente

El stack actual de telemetría de TLSStress.Art tiene 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 convierte en el 5º pilar:

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

Críticamente, ninguno de los pilares existentes se elimina. SNMP permanece para contadores de UCS + NGFW. Syslog permanece para eventos. REST API permanece para configuración + estado de decrypt-policy en NGFW + salud de hardware UCS.

Qué ganamos al añadir gNMI

Capacidad Sin gNMI (hoy) Con gNMI
Contadores por interfaz (Nexus) SNMP ifTable consultado cada 30–60 s STREAM SAMPLE sub-segundo
Profundidad de cola + drops (QoS Nexus) SNMP, frecuentemente ausente para features de ASIC más nuevos Modelo OpenConfig qos:queues
Niveles ópticos en transceivers SNMP entSensorTable parcial OpenConfig terminal-device:optical-channel
Utilización de TCAM (filter NGFW, ACL Nexus) SNMP parcial, específico de vendor OpenConfig + YANG Cisco, sub-segundo
Transiciones de estado (interfaz up/down) Polled a la cadencia de SNMP — pierde flaps <1 s STREAM ON_CHANGE captura cada transición
Soporte multi-vendor de switches Mapeo MIB por vendor en el código Los mismos paths de Subscribe funcionan en Cisco/Juniper/Arista

La victoria destacada: cuando un puerto Nexus hace flap durante 800 ms en una ejecución, SNMP se lo pierde; gNMI lo captura. Esta es la diferencia entre "spike de p99 sin causa aparente" y "spike de p99 correlacionado con flap de puerto a las 14:32:01.812".

Qué NO ganamos

Para ser preciso sobre el alcance:

  • ❌ Estado de decrypt policy del NGFW — no existe modelo OpenConfig YANG para reglas de decrypt específicas del vendor
  • ❌ Térmica / energía / ECC de DIMM del UCS — UCS no habla gNMI
  • ❌ Semántica de deploy state del FTD (la noción "DEPLOYED / PENDING" de FDM) — solo FDM REST
  • ❌ Reemplazo de SNMP en UCS — UCS depende de SNMP/Redfish para hardware

Lo que SÍ ganamos en el FTD gestionado por cdFMC (corrección respecto al borrador anterior):

  • ✅ Contadores de interfaz (bytes, errors, drops por puerto) a cadencia ≥1-min
  • ✅ Notificaciones ON_CHANGE para transiciones de estado de interfaz
  • ✅ Modelos OpenConfig a nivel de sistema (CPU, memoria, procesos)
  • ✅ Consistencia de queries multi-vendor — el mismo path Subscribe funciona en Cisco FTD + Cisco Nexus + Juniper + Arista cuando esos sean añadidos

Si lees marketing afirmando que "gNMI reemplaza todo", esa afirmación sigue siendo errónea — pero para usuarios de cdFMC reemplaza un subconjunto significativo de lo que actualmente recolectamos vía REST + SNMP.

Tres opciones arquitectónicas (con trade-offs)

Opción A — Cliente gNMI nativo dentro del pod del dashboard (Node.js)

Implementar el cliente gNMI en TypeScript dentro del proceso del dashboard Next.js.

Pro Con
Cero contenedores nuevos Las librerías gNMI del ecosistema Node son inmaduras (los mejores clients son Go + Python)
Único deployment Las subscriptions gRPC de larga duración dentro del proceso Next.js arriesgan problemas de memoria
Reutiliza Postgres + auth de admin existentes La lógica de gRPC keepalive + reconnect en JS es frágil

Veredicto: 🚫 No recomendado.

Opción B — Microservicio Go dedicado

Construir un pequeño servicio Go (~500 LoC) usando github.com/openconfig/gnmi. Lee la lista de dispositivos desde una tabla Postgres dut_gnmi_devices, establece streams Subscribe, traduce updates en métricas Prometheus O escribe en una tabla dut_gnmi_samples.

Pro Con
Go tiene librerías gNMI maduras Nueva imagen de contenedor — infla el bundle de air-gap
Manejo nativo de gRPC + HTTP/2 + TLS Nuevo lenguaje para que el equipo mantenga
Las subscriptions de larga duración son la fortaleza de Go Superficie de deployment más compleja
Separa el dominio de fallo del dashboard

Veredicto: ✅ Respuesta correcta cuando gNMI es una prioridad de producto (no solo exploración).

Opción C — Sidecar gnmic (recomendado para la primera iteración)

gnmic es la herramienta CLI open-source que es el cliente gNMI de facto en observabilidad de red. Ejecútalo como un Deployment Kubernetes con configuración vía ConfigMap. Trae salida integrada para Prometheus exporter, Loki, InfluxDB, NATS.

Pro Con
Cero código gNMI que mantenemos — gnmic es maduro, open-source Dos sistemas de configuración (REST API en Postgres, gNMI en ConfigMap YAML)
Modo Prometheus exporter nativo encaja en nuestro stack Menos control sobre el formato de los datos
~2 días de trabajo de operador + ops, sin código nuevo Imagen gnmic para empaquetar en air-gap
Valida el caso de uso rápidamente con baja inversión El operador gestiona la configuración de gnmic por separado de la del dashboard

Veredicto: ✅ Recomendado para la Fase 1.

Plan por fases

Fase 0 — Este documento (AHORA)

  • ✅ Documento de roadmap publicado en 3 idiomas
  • ✅ Matriz honesta de soporte de vendors
  • ✅ Opciones arquitectónicas analizadas
  • ✅ Justificación de decisiones documentada para futuros operadores / clientes / Cisco Legal

Ningún código entregado. Esta fase trata de conocimiento institucional — cuando alguien pregunta "¿soportan gNMI?", apuntamos a este documento.

Fase 1 — Sidecar gnmic (tras validación en producción del v1.0)

Trigger: TLSStress.Art ha sido desplegado en al menos un lab real, la telemetría existente de 4 pilares ha sido validada de extremo a extremo, y hay demanda del operador por telemetría de switch sub-segundo.

Alcance (~2 días de trabajo): 1. k8s/optional/gnmic-sidecar.yaml — Deployment + ConfigMap con configuración gnmic 2. Paths de subscription gNMI por dispositivo Nexus (interfaces, qos, system) 3. Modo Prometheus exporter emitiendo series bajo el namespace tlsstress_gnmi_* 4. Dashboard Grafana "TLSStress.Art — Nexus Sub-Second Telemetry" leyendo de esas métricas 5. docs/GNMI_OPERATIONS.{md,pt-BR.md,es.md} — guía del operador para habilitar feature grpc en el Nexus + registrar paths en la configuración de gnmic

Fuera del alcance de la Fase 1: - Soporte multi-vendor (solo Cisco Nexus inicialmente) - Operaciones Set (solo lectura) - Integración Loki para ON_CHANGE (Fase 2) - Metadatos gNMI en las tablas de snapshots de la DUT API (Fase 2)

Fase 2 — Microservicio Go dedicado (v2.0)

Trigger: La Fase 1 ha probado el caso de uso gNMI en al menos un lab real Y hay demanda por (a) operaciones de escritura, (b) más vendors, o (c) integración más profunda con el flujo existente de snapshot / report.

Alcance (~1–2 semanas de trabajo): 1. services/gnmi-collector/ — microservicio Go, ~500-1000 LoC 2. Tabla dut_gnmi_devices — registra dispositivos que hablan gNMI (auth basada en cert) 3. Tabla dut_gnmi_samples — almacenamiento de largo plazo para muestras de alto valor 4. Integración Loki para eventos ON_CHANGE 5. Soporte multi-vendor: Cisco Nexus + Juniper Junos + Arista EOS 6. Anexo E "evidencia de streaming gNMI" del Test Run Report con timing sub-segundo junto a la ventana de la ejecución 7. Soporte opcional de operación Set con el mismo flujo de confirmación del operador usado para escrituras vía REST API

Fase 3 — Reemplazar el sidecar gnmic por el servicio Go (v2.x)

Si la Fase 2 entrega y es estable, el sidecar gnmic se vuelve redundante. Lo retiramos. Los operadores con deployments de la Fase 1 son migrados desplegando el servicio Go al lado, ejecutando en paralelo durante una release, luego apagando gnmic.

Por qué NO estamos entregando la Fase 1 en esta iteración

Razonamiento honesto:

  1. Los PRs existentes en cola necesitan aterrizar primero — añadir gNMI sobre una cola no estabilizada agrava la complejidad de merge
  2. Aún no hay test de extremo a extremo en hardware real — añadir más pilares de telemetría antes de validar los existentes es optimización prematura
  3. gNMI ayuda predominantemente a switches — tenemos un switch (Cisco Nexus). 1 hora de configuración gnmic eventualmente nos dará lo que necesitamos, sin nuevo microservicio
  4. Spirent / Ixia tampoco tienen gNMI — añadirlo nos posiciona para el futuro, pero no nos pone "por delante" de los competidores hoy; ya estamos por delante vía el patrón de adapter multi-vendor
  5. Complejidad para el operador — cada nuevo pilar = otro dashboard que el operador debe aprender. Hasta que los dashboards existentes prueben su valor en producción, añadir más es overhead

La jugada "por delante de los competidores" en este momento es operacionalizar lo que tenemos: pre-flight checks (PR-C), wiring de la Fase 3 del Test Run Report (PR-D), validación en lab real. No añadir más fuentes de telemetría.

Cuándo SÍ entregaremos la Fase 1

Condiciones de trigger, todas las cuales deben ser verdaderas:

  • Al menos un deployment en lab real con los 4 pilares existentes ejercitando de extremo a extremo
  • Test Run Report Fase 3 (Anexos B/C/D) entregado y validado
  • PR-C (pre-flight checks) entregado y ejercitado en una ejecución real
  • Un operador ha pedido explícitamente telemetría de switch sub-segundo
  • Cisco Nexus 9000 está en un lab de cliente + tenemos credenciales

Cuando las cuatro casillas estén marcadas, la Fase 1 es ~2 días de trabajo.

Comparación de capacidades vs alternativas comerciales

Feature Spirent CyberFlood Ixia BreakingPoint TLSStress.Art (con Fase 1 gNMI)
Soporte de subscription gNMI ❌ ❌ ✅ (Cisco Nexus inicialmente)
Modelos YANG OpenConfig ❌ ❌ ✅
Switch multi-vendor vía gNMI ❌ ❌ ✅ (Fase 2)
Telemetría de puerto sub-segundo ⚠️ derivada de SNMP, atada al vendor ⚠️ atada al vendor ✅
Arquitectura abierta ❌ ❌ ✅

El diferenciador estructural es la arquitectura abierta multi-vendor. gNMI la refuerza; no es la fuente de ella.

Referencias

Relacionados