9. La Red#

La automatización de VLANs llevaba tres semanas funcionando en el laboratorio. Tres switches, uno de cada proveedor, todos los flujos de trabajo pasando. El equipo se sentía seguro. En el primer despliegue en producción, 23 de los 800 switches de campus fallaron. Todos HPE. Todos con una versión de firmware que nadie había documentado.

El playbook comprobaba la respuesta de error de cada dispositivo tras enviar la configuración de VLAN. En el firmware HPE moderno, una VLAN ya existente devuelve el código de error duplicate-vlan. En esta versión anterior del firmware, la misma condición devolvía vlan-exists. El playbook se había escrito para tratar duplicate-vlan como una señal de idempotencia, es decir, “esto ya existe, está bien”. No se había escrito para manejar vlan-exists, por lo que trataba esa respuesta como un fallo. Un tercio de la flota HPE reportó fallo. El rollback se ejecutó limpiamente. El ticket del equipo de aplicaciones permaneció abierto tres horas más mientras el equipo de red auditaba manualmente qué switches habían sido configurados realmente y cuáles no.

La automatización no estaba equivocada. La red tenía una opinión que nadie había documentado.

Seis meses después, el mismo equipo tenía una topología de containerlab que reflejaba el Edificio B: 24 switches, imágenes de proveedor coincidentes, con los nodos HPE bloqueados a la versión de firmware en producción registrada en la Source of Truth (SoT). En la primera ejecución de prueba del flujo de trabajo de VLAN contra esa topología, 8 nodos HPE fallaron exactamente con ese código de error. El equipo añadió vlan-exists a la lista de respuestas idempotentes en el adaptador HPE. Nueva ejecución: los 24 nodos pasaron. Despliegue en producción: 800 switches, cero fallos.

La diferencia no fue mejor código. Fue un entorno de pruebas que representaba la realidad.

Este capítulo aborda el bloque que fue siempre implícito a lo largo de la Parte 2: la red en sí misma. Todos los bloques constructivos construidos hasta ahora fueron diseñados por el equipo de automatización y se comportan de acuerdo con sus interfaces documentadas. La red fue heredada. Tiene peculiaridades, interfaces diversas, inconsistencias de firmware y capacidades que varían según el proveedor, la plataforma y la generación de software. El Capítulo 9 aborda dos preguntas: ¿qué necesitamos de la red para que la automatización sea fiable? ¿Y cómo validamos la lógica de automatización de forma segura antes de que toque producción?

9.1. Fundamentos#

9.1.1. Contexto#

El Capítulo 3 introdujo La Red como uno de los siete bloques del NAF Framework: el único bloque que el equipo de automatización no “posee” (está en el ámbito de la ingeniería de redes). Lo configuran, lo observan y modelan su intención, pero no construyeron el sistema operativo, el modelo de datos ni la interfaz de API. Esa dependencia moldea cada decisión de diseño en la plataforma que hay encima.

El Capítulo 5 cubrió en detalle el camino de escritura del Executor: cómo operan los roles de automatización, las tareas parametrizadas y las comprobaciones de idempotencia. Lo que el Capítulo 5 da por sentado es que el dispositivo en el otro extremo expone una interfaz fiable y consistente. El Capítulo 9 aborda si esa suposición se cumple, y qué hacer cuando no.

El Capítulo 6 cubrió el camino de lectura del Collector: telemetría en streaming con gRPC Network Management Interface (gNMI), sondeo SNMP y el pipeline de normalización de datos. El Capítulo 9 cubre los prerrequisitos del lado del dispositivo para esos caminos: qué debe ser cierto sobre el dispositivo de red para que el colector pueda leer de él de forma consistente.

El Capítulo 9 cierra la Parte 2. Los seis capítulos anteriores construyeron la plataforma de automatización: un lugar para almacenar la intención, una forma de ejecutarla, una forma de observar los resultados, un motor para coordinar todo y superficies para exponerlo a los consumidores. Este capítulo aborda la cosa a la que la plataforma siempre apuntaba.

9.1.2. Objetivos#

Tres objetivos definen la contribución del bloque La Red a la plataforma de automatización:

1. Entender y navegar el espectro completo de la infraestructura de red. Cualquier plataforma de automatización a gran escala puede hablar simultáneamente con switches de campus, fabrics de centros de datos, VPCs en la nube, overlays de Kubernetes, controladores de overlay y equipos legacy. Cada tipo expone diferentes interfaces programables. La plataforma debe manejar todos ellos sin colapsar en una única abstracción de mínimo común denominador.

2. Validar la lógica de automatización y apoyar el diseño de nuevas arquitecturas de red antes de tocar producción. Los entornos de simulación sirven dos propósitos: son la puerta de pre-producción donde los errores lógicos, las violaciones de contratos de interfaz y las peculiaridades específicas del dispositivo se detectan al coste de minutos en un laboratorio en lugar de horas en un incidente de producción, y son el entorno de diseño donde se exploran y validan nuevas arquitecturas de red antes de pedir hardware.

3. Mantener la plataforma de automatización estable a medida que la red evoluciona. Se añaden nuevos proveedores. Las versiones de firmware cambian. Llegan nuevos tipos de infraestructura. La plataforma debe diseñarse para absorber este cambio mediante estrategias de abstracción, no mediante parches ad-hoc en cada flujo de trabajo cada vez que la red cambia.

9.1.3. Pilares#

Tres pilares dan soporte a estos objetivos, uno por funcionalidad:

1. Espectro de infraestructura de red e interfaces programables: el rango completo de tipos de red que la plataforma debe automatizar, y la interfaz que cada tipo expone al Ejecutor y al Colector.
2. Entornos de simulación y pruebas: la cadena de herramientas para la validación pre-producción. Dónde encajan los distintos tipos de entorno de laboratorio, cómo se conectan con el patrón Saga del Capítulo 7 y cómo escalarlos.
3. Estrategias de abstracción: enfoques estructurales que permiten a la plataforma de automatización mantenerse estable a medida que cambia la red subyacente, independientemente del proveedor, la generación de plataforma o el protocolo de interfaz.

9.1.4. Alcance#

Dentro del alcance:

• Las interfaces a través de las cuales el Ejecutor y el Colector alcanzan los dispositivos de red. Tanto NETCONF como gNMI soportan operaciones de configuración y telemetría; la elección entre ellos por caso de uso depende de las fortalezas operativas, no de la exclusividad del protocolo. El protocolo a menudo se comparte entre bloques; el tipo de operación difiere.
• Los entornos y metodologías de pruebas que validan la automatización antes de producción
• Estrategias de abstracción para gestionar la heterogeneidad multi-proveedor y multi-plataforma
• Las implicaciones de la nube, Kubernetes y las redes overlay para el diseño de automatización

Fuera del alcance:

• Generación de configuración y renderización de plantillas (Source of Truth (SoT), Capítulo 4)
• Mecánica de ejecución: cómo las herramientas de automatización ejecutan una tarea (Ejecutor, Capítulo 5)
• El pipeline de recopilación de telemetría: cómo fluyen las métricas hacia la base de datos de series temporales (Observability, Capítulo 6)

El límite es consistente: el Capítulo 9 cubre el lado de la red de cada interfaz, no el lado de la plataforma.

9.2. Funcionalidades#

El bloque La Red es el único bloque constructivo del framework NAF que la plataforma de automatización no controla. Solo puede interactuar con la red como la red lo permite. Cada decisión de diseño en los cinco capítulos anteriores, cómo se almacena la intención, cómo se ejecuta, cómo se recopila la telemetría, cómo se coordinan los flujos de trabajo, cómo se sirve a los consumidores, se resuelve en última instancia en una pregunta sobre qué soporta el dispositivo de red en el otro extremo de la conexión. Este capítulo examina directamente esa restricción.

graph LR

    subgraph Goals["Objetivos"]
        direction TB
        A1[Navegar por el espectro completo de infraestructura de red]
        A2[Validar la automatización antes de producción]
        A3[Mantener la plataforma estable a medida que la red evoluciona]
    end

    subgraph Pillars["Pilares"]
        direction TB
        B1[Espectro de infraestructura de red e interfaces programables]
        B2[Entornos de simulación y pruebas]
        B3[Estrategias de abstracción]
    end

    subgraph Functionalities["Funcionalidades"]
        direction TB
        C1[Interfaces Programables]
        C2[Entornos de Simulación y Pruebas]
        C3[Estrategias de Abstracción]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;

9.2.1. Interfaces Programables#

La red es heterogénea por naturaleza. No es una sola cosa. Es un espectro de tipos de infraestructura acumulados a lo largo de los años, a menudo construido en paralelo por diferentes equipos (la titularidad y los límites organizacionales se exploran en el Capítulo 13), cada uno con su propio modelo de interfaz, nivel de abstracción y madurez en la automatización. Una plataforma de automatización moderna puede abarcar simultáneamente switches de campus, fabrics de centros de datos, VPCs en la nube, controladores de overlay, clústeres de Kubernetes, infraestructura WAN de proveedores de servicios y planos de reenvío gestionados por hyperscalers. La plataforma debe manejar todos ellos. El tipo de infraestructura determina qué interfaz está disponible; la plataforma de automatización se adapta a esa realidad en lugar de imponer una interfaz uniforme.

9.2.1.1. El espectro de infraestructura de red#

Este es un resumen de alto nivel de los distintos escenarios de infraestructura de red que puede ser necesario abordar, dependiendo de la naturaleza de la empresa:

• Switching de campus y sucursales es el escenario principal usado como ejemplo a lo largo de la Parte 2: switches físicos multi-proveedor (Cisco, Arista, HPE, Extreme). Los equipos de campus modernos exponen Command Line Interface (CLI), NETCONF y gRPC Network Management Interface (gNMI) simultáneamente. La madurez en automatización es alta para equipos de los últimos cinco a siete años; es irregular para equipos legacy que aún corren firmware de hace una década.

• Fabric de centro de datos con topología leaf-spine, a menudo de un conjunto más reducido de proveedores: Arista, Cisco Nexus o plataformas de open networking nativas para automatización. La uniformidad de interfaces es mayor que en el campus; la gestión de cambios es más estricta. Los overlays EVPN/VXLAN añaden un plano de gestión por encima del fabric que puede tener su propia API, separada de la interfaz del dispositivo individual. Las plataformas basadas en SONiC (Cisco 8000, Nvidia Spectrum) están cada vez más presentes en despliegues DC influenciados por los hyperscalers; su interfaz de configuración es una base de datos estructurada en lugar de CLI o NETCONF, y se trata más adelante en la sección de estrategias de abstracción.

• Infraestructura WAN y de proveedor de servicios (routers de grado operador, redes MPLS, fabrics de segment routing) tiene sus propios retos de automatización: escala, complejidad de protocolos y la doble preocupación de la configuración del plano de control y la política de ingeniería de tráfico. NETCONF y los modelos YANG están bien establecidos en este espacio; proveedores como Cisco IOS-XR y Junos tienen una cobertura YANG madura. La plataforma de automatización a menudo apunta a un controlador (SR-PCE, Crosswork, NSO) en lugar de a dispositivos individuales.

• Redes en la nube: AWS VPC, Azure VNet, GCP VPC y otros. APIs REST con semántica de consistencia eventual. No hay concepto de “enviar una configuración” y esperar una confirmación síncrona. El Ejecutor maneja operaciones asíncronas: crear, sondear, verificar. Las herramientas de infraestructura como código encajan en este modelo de forma natural. La plataforma de automatización debe tener en cuenta el diferente modelo de consistencia, no asumir una semántica de aplicar-y-confirmar síncrona.

• SD-WAN y redes overlay (Cisco SD-WAN, Versa, VMware VeloCloud) son gestionadas por controladores. El objetivo de automatización es la API del controlador, no el dispositivo individual. El underlay físico sigue existiendo pero se gestiona completamente a través de la abstracción del overlay. Esto afecta tanto a la ejecución como a la observabilidad: el Ejecutor escribe políticas en el controlador; la telemetría sobre el tráfico, la selección de camino y la aplicación de políticas también fluye a través de la interfaz northbound del controlador, no directamente desde los dispositivos de underlay físico.

• Redes Kubernetes en la capa CNI invierte completamente el modelo de dispositivo. La red se define a través de objetos de API de Kubernetes: NetworkPolicy, Services, Ingress y recursos personalizados de plugins CNI como Cilium, Calico o Flannel. El dispositivo desaparece como objetivo de automatización. La API de Kubernetes es la interfaz. Las políticas de red son código, no configuración de dispositivo. Este es el modelo hacia el que convergen los demás: intención declarativa, estado reconciliado por el controlador, sin acceso directo al dispositivo.

• DPUs y SmartNICs (Nvidia BlueField, Intel IPU, Marvell Octeon) representan un cambio en dónde ocurre el procesamiento de red. En los centros de datos modernos, las DPUs se instalan junto a las CPUs en cada servidor para descargar funciones de red: encapsulación VXLAN, cifrado, aplicación de políticas de firewall, balanceo de carga y microsegmentación. Esto descarga estas funciones de la CPU del host y de los appliances de red hacia el firmware del SmartNIC. La consecuencia para la automatización: “el dispositivo de red” ya no es solo un switch o router en el rack. Las funciones antes gestionadas a través de APIs dedicadas de appliances de red ahora se gestionan a través del plano de gestión de la DPU y su SDK de proveedor, una nueva categoría de interfaz que las herramientas estándar de NETCONF y gRPC Network Management Interface (gNMI) aún no alcanzan limpiamente.

• Open networking (SONiC, DENT, OPX) ejecuta software Network Operating System (NOS) en hardware commodity. La interfaz de configuración de SONiC es una base de datos Redis con un esquema estructurado según Yet Another Next Generation (YANG), estructuralmente diferente de CLI o NETCONF, y programática por diseño. Está cada vez más presente en centros de datos empresariales a gran escala y en despliegues DC influenciados por hyperscalers. SONiC es notable porque fue diseñado para automatización desde el principio: la interfaz es una base de datos estructurada, no una CLI adaptada para acceso programático.

• Funciones de red virtuales coexisten con la infraestructura física en muchos entornos. Un firewall software que inserta tráfico a través de caminos definidos por políticas, un balanceador de carga virtual que gestiona la distribución de tráfico entre clústeres de aplicaciones, un reflector de rutas BGP basado en software: todos son objetivos de automatización que usan interfaces de gestión que van desde APIs REST de proveedor hasta NETCONF. A menudo se gestionan junto con el inventario físico usando la misma SoT y Ejecutor, pero requieren rutas de adaptador separadas porque sus modelos de interfaz difieren de los dispositivos físicos.

• Controladores wireless (Cisco DNA, Aruba Central, Juniper Mist) están basados en controladores; el objetivo de automatización es la API del controlador. Relevante siempre que el aprovisionamiento de VLANs se extienda a SSIDs wireless junto con puertos de switch cableados, como ocurriría en el escenario de campus.

El punto no es enumerar exhaustivamente cada tipo de infraestructura. Es establecer que una plataforma que automatiza cualquier red no trivial interactúa con múltiples tipos simultáneamente. El Ejecutor y el Colector deben enrutar cada operación al tipo de interfaz correcto. La Source of Truth (SoT) debe modelar la intención a un nivel por encima de la interfaz individual. La complejidad de la red es la restricción de diseño que la plataforma fue construida para absorber.

9.2.1.2. Tipos de interfaz#

Cada tipo de infraestructura expone uno o más tipos de interfaz a la plataforma de automatización. El mismo switch físico puede exponer los tres simultáneamente. La plataforma se adapta a lo que está disponible, con preferencias que reflejan fiabilidad, estructura y escala. Ningún tipo de interfaz es un mandato universal; la elección correcta depende de qué soporte el dispositivo y qué requiera la operación.

• Command Line Interface (CLI) sobre Secure Shell (SSH) es universal, legacy y frágil. El screen-scraping y el análisis de texto se rompe cuando el firmware cambia el formato de salida o añade nuevos campos. Los códigos de error son inconsistentes entre proveedores y entre versiones de firmware. La CLI sigue siendo la única opción para equipos más antiguos. La recomendación es minimizar su uso y evitar construir flujos de trabajo que dependan de ella para algo más que los dispositivos que no tienen alternativa (el último recurso). Configurar una descripción de interfaz se ve así:

interface GigabitEthernet0/1
 description uplink-to-core

• NETCONF es estructurado, transaccional y correcto cuando funciona. Soporta operaciones atómicas y rollback, y su modelo de datos es analizable por máquinas. La capa de transporte es generalmente fiable; la capa del modelo de datos es donde están las lagunas. La calidad del modelo YANG de los proveedores varía significativamente: un dispositivo puede declarar soporte NETCONF pero tener modelos incompletos o propietarios para las características que necesita la plataforma. Los modelos YANG de IETF y OpenConfig estandarizan la capa de intención; los modelos YANG nativos del proveedor llenan las lagunas. La misma descripción de interfaz vía NETCONF:

<config>
  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
      <name>GigabitEthernet0/1</name>
      <description>uplink-to-core</description>
    </interface>
  </interfaces>
</config>

• RESTCONF es el equivalente HTTP de NETCONF, usando los mismos modelos YANG pero expuestos sobre semántica REST. Es útil cuando los equipos se sienten más cómodos con herramientas HTTP que con el transporte XML/SSH de NETCONF. El modelo de datos es el mismo; solo el transporte difiere. El soporte de los proveedores es menos uniforme que NETCONF. La misma descripción de interfaz vía RESTCONF:

PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F1
Content-Type: application/yang-data+json

{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet0/1",
    "description": "uplink-to-core"
  }
}

• gRPC Network Management Interface (gNMI) y gNOI son protocolos basados en gRPC Remote Procedure Call (gRPC). gRPC Network Management Interface (gNMI) maneja telemetría y lectura/escritura de configuración; gNOI maneja comandos operativos. Modernos y amigables para la escala. El soporte de los proveedores es maduro en Arista y las plataformas Cisco más nuevas; es irregular en HPE y equipos legacy. El Capítulo 6 cubrió gNMI desde la perspectiva del Colector. El Capítulo 9 cubre los prerrequisitos del lado del dispositivo: el dispositivo debe soportar suscripciones gNMI en la versión de OS que apunta la plataforma. Los switches Nvidia Spectrum con SONiC exponen gNMI de forma nativa junto con la interfaz CONFIG_DB, convirtiéndolos en una de las plataformas más amigables para la automatización tanto para configuración como para telemetría. La misma descripción de interfaz vía gNMI SetRequest:

path:  /interfaces/interface[name=GigabitEthernet0/1]/config/description
value: "uplink-to-core"

• APIs REST de proveedor (eAPI, NX-API, Cumulus NVUE y similares) son legibles por máquinas pero no están estandarizadas entre proveedores. Útiles como complemento cuando NETCONF o gNMI está ausente o incompleto para una operación específica. Los switches Nvidia Cumulus exponen NVUE (una API REST estructurada con esquema JSON consistente) como su interfaz programática principal; Arista y Cisco Nexus exponen eAPI y NX-API respectivamente como alternativas a NETCONF. Tratar estos como preocupaciones de la capa de adaptador, no como base para una plataforma neutral al proveedor. La misma descripción de interfaz vía Arista eAPI (JSON-RPC sobre HTTPS):

{
  "jsonrpc": "2.0",
  "method": "runCmds",
  "params": {
    "version": 1,
    "cmds": [
      "interface GigabitEthernet0/1",
      "description uplink-to-core"
    ],
    "format": "json"
  },
  "id": "1"
}

• APIs de nube y controladores siguen patrones REST con consistencia eventual. El modelo de operación asíncrona es un requisito de diseño, no una limitación a solventar. Para SD-WAN, wireless y planos de gestión de DPU, la API del controlador es a menudo la única interfaz disponible. Añadir una descripción a una VPC de AWS ilustra el patrón: una actualización de recurso etiquetado enviada de forma asíncrona, sin confirmación síncrona de que el cambio fue aplicado:

POST https://ec2.eu-west-1.amazonaws.com/ HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: AWS4-HMAC-SHA256 ...

Action=CreateTags
&ResourceId.1=vpc-0a1b2c3d4e5f67890
&Tag.1.Key=Description
&Tag.1.Value=uplink-to-core
&Version=2016-11-15

• La API de Kubernetes es declarativa, reconciliada por el controlador y consistente entre proveedores. NetworkPolicy, Services y los recursos personalizados CNI son los objetivos de automatización. No hay acceso directo al dispositivo; el servidor de API es la única interfaz. Una política de aislamiento de red para el servicio app-payments:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-payments-isolation
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: app-payments
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: app-payments

• SONiC CONFIG_DB (Redis) es la interfaz nativa para plataformas basadas en SONiC. En lugar de un protocolo superpuesto al OS, es el propio almacén de configuración del OS: una base de datos Redis con un esquema estructurado según YANG. La automatización escribe entradas JSON directamente en CONFIG_DB; el daemon interno orchagent de SONiC reconcilia la intención con las tablas de reenvío del hardware. gNMI está disponible en paralelo para lecturas de telemetría. Esto es arquitectónicamente distinto de CLI, NETCONF o REST: la interfaz es el propio almacén de datos. La misma descripción de interfaz escrita en CONFIG_DB vía JSON patch (aplicado con config load):

{
  "PORT": {
    "Ethernet0": {
      "description": "uplink-to-core",
      "admin_status": "up"
    }
  }
}

9.2.1.3. Selección de interfaz por dispositivo#

Cuando un dispositivo expone múltiples interfaces, la plataforma debe elegir una por tipo de operación y mantener esa elección de forma consistente. Un switch de campus que expone Command Line Interface (CLI), NETCONF y gRPC Network Management Interface (gNMI) simultáneamente requiere una decisión, no un enfoque de mezcla y combinación que varía por flujo de trabajo o preferencia del ingeniero.

Jerarquía recomendada, aplicada por tipo de operación. Tanto gRPC Network Management Interface (gNMI) como NETCONF soportan escrituras de configuración y lecturas de telemetría; la preferencia a continuación refleja fortalezas operativas, no exclusividad del protocolo:

• gRPC Network Management Interface (gNMI) preferido para la recopilación de telemetría (suscripciones de streaming, estructurado, amigable para la escala; gNMI Set es también un camino de configuración válido)
• NETCONF preferido para la configuración (transaccional, con capacidad de rollback; NETCONF get y get-config son igualmente válidos para lecturas de estado)
• RESTCONF o API REST de proveedor como alternativa cuando NETCONF está incompleto para una característica específica
• Command Line Interface (CLI) como último recurso solo para equipos legacy

Lo que el Ejecutor necesita de la interfaz: Idempotency o al menos códigos de error fiables que distingan “ya existe” de “fallo”, respuestas de error estructuradas y capacidad de verificación del estado tras la aplicación. El problema de HPE vlan-exists frente a duplicate-vlan fue precisamente un fallo de la segunda condición: la semántica del código de error cambió entre versiones de firmware.

Lo que el Colector necesita: lecturas estructuradas, suscripciones de telemetría en streaming y modelos de datos consistentes para que la capa de Observabilidad no necesite parsers por dispositivo. gRPC Network Management Interface (gNMI) es el protocolo de suscripción preferido donde está soportado: es estructurado, jerárquico y validado por esquema en el dispositivo, lo que elimina el análisis de texto por dispositivo que dominaba la recopilación de la era SNMP. Pero cualquier mecanismo de suscripción que entregue datos estructurados y oportunos sirve la misma función. El sondeo SNMP sigue siendo válido para dispositivos legacy donde gNMI no está disponible. Syslog alimenta eventos estructurados para la observabilidad basada en logs. OpenTelemetry (OTel) es un estándar emergente que vale la pena seguir: originalmente diseñado para la observabilidad de aplicaciones, está ganando adopción como transporte neutral al proveedor para telemetría de red, métricas y trazas. La elección de protocolo del Colector es una función de lo que soporte el dispositivo; la capa de Observabilidad no debería necesitar saber qué transporte se usó.

La Source of Truth (SoT) registra el estado previsto para cada atributo del dispositivo sobre el que opera la plataforma: configuración VLAN prevista, relaciones de vecinos BGP previstas, descripciones de interfaz previstas y versión de OS prevista. La versión de OS merece una mención especial aquí porque afecta no solo a la detección de deriva de configuración sino a la propia selección del camino del adaptador: el Ejecutor bifurca por versión de OS cuando el firmware del mismo proveedor se comporta de forma diferente entre releases. Esto no es un caso especial para la versión de OS; es el mismo patrón de intención-versus-realidad aplicado a cada atributo que gestiona la plataforma. La versión de OS deseada es la que aprobó el equipo de operaciones; la versión en ejecución es lo que observa la Observabilidad. Cuando divergen, esa divergencia es una señal: el dispositivo puede estar atrasado en una actualización planificada, o ocurrió un cambio no planificado. La plataforma necesita ambos puntos de datos para decidir si proceder o bloquear.

Esta distinción importa en la práctica. La SoT dice que un dispositivo debería correr AOS-CX 10.13. El Colector reporta que está corriendo 10.12.1006. La plataforma tiene dos opciones: bloquear la ejecución hasta que se reconcilie la versión de OS, o proceder usando el camino del adaptador de 10.12. La respuesta correcta depende de la política de gestión de cambios del equipo, pero la plataforma necesita ambos puntos de datos para tomar la decisión. La SoT proporciona la intención; la Observabilidad proporciona la realidad.

9.2.2. Entornos de Simulación y Pruebas#

La red es infraestructura de producción. A diferencia de un backend de aplicación, no hay un servidor de staging contra el que probar por defecto. Construir uno es el trabajo de esta funcionalidad.

Probar la automatización de redes siempre ha sido más difícil que probar el código de aplicaciones. Una red es un sistema distribuido con muchos componentes que el equipo de automatización no controla: ASes vecinos en puntos de peering, proveedores de tránsito upstream, CPE gestionado por el cliente, clientes wireless e infraestructura cloud operada por terceros. Un proveedor de servicios que prueba un cambio de política de enrutamiento no puede levantar un peer BGP simulado de un proveedor de tránsito para validar el comportamiento completo. Una empresa que prueba un flujo de trabajo de failover WAN no puede controlar cómo responde el proveedor MPLS. Los entornos de simulación descritos en esta sección son el mejor sustituto disponible: reproducen lo que el equipo controla, aceptan las limitaciones de lo que no pueden, y centran la validación en la capa lógica donde realmente viven los bugs.

La pirámide de pruebas del Capítulo 2 (unitarias, de integración, de extremo a extremo) se aplica directamente aquí. Las pruebas unitarias validan módulos individuales de automatización de forma aislada, típicamente con respuestas simuladas del dispositivo. Las pruebas de integración validan interacciones de múltiples pasos: la API de la SoT devuelve la estructura de datos esperada, el Ejecutor la traduce correctamente, la respuesta del dispositivo se maneja correctamente. Las pruebas de extremo a extremo validan el flujo de trabajo completo contra algo que se comporta como un dispositivo de red real. Los entornos de simulación son la capa de extremo a extremo.

9.2.2.1. Tipos de entorno#

El entorno correcto depende de qué necesita validar la prueba. Hay un espectro desde entornos de baja fidelidad y bajo coste apropiados para pipelines CI/CD rutinarios, hasta entornos de alta fidelidad que merece la pena invertir para pruebas con confianza de producción.

• La emulación basada en contenedores usa imágenes ligeras de OS de red ejecutándose como contenedores, conectados por enlaces virtuales. El arranque de la topología tarda segundos. Es la opción práctica por defecto para CI/CD rutinario: el equipo de automatización ejecuta el mismo código de flujo de trabajo contra una topología containerizada en cada cambio, detectando errores lógicos antes de producción. El comportamiento del plano de datos no se reproduce, pero el comportamiento del plano de control y de la interfaz de gestión son suficientes para probar la lógica de automatización.

• La emulación basada en VM ejecuta imágenes completas de NOS como máquinas virtuales. Proporciona una cobertura de proveedor más amplia, un comportamiento de NOS más realista incluyendo el plano de datos, y es apropiada para pruebas de diseño de protocolos y escenarios de interoperabilidad multi-proveedor. La contrapartida: mayor coste de recursos, arranque más lento y limitada integración con pipelines automatizados. No es práctica para pruebas rutinarias a nivel de commit.

• Los laboratorios de hardware físico son mantenidos por muchas organizaciones grandes: un rack de switches y routers reales, a menudo reflejando los patrones de arquitectura de producción. Esto proporciona la mayor fidelidad para comportamientos específicos del hardware, pruebas de rendimiento y escenarios donde la emulación no reproduce con precisión el comportamiento del dispositivo. El coste es significativo: inversión de capital, energía y espacio, y la carga operativa de mantener la topología del laboratorio sincronizada con la arquitectura de producción. Los laboratorios que divergen de los patrones de producción proporcionan una falsa confianza. El valor es real; la disciplina de mantenimiento es el reto.

• Los gemelos digitales son réplicas en vivo de la topología de producción, alimentadas por la Fuente de Verdad (mismos modelos de dispositivos, topología y configuración prevista actual) y el estado actual de la Observabilidad. Un gemelo digital refleja cómo se ve producción en este momento, no una aproximación. El coste operativo es significativo: mantener la sincronización entre el gemelo digital y producción requiere una reconciliación continua. Es una inversión de nivel de madurez, apropiada para equipos que ya han validado su plataforma a escala y necesitan el mayor nivel de confianza pre-producción.

La emulación basada en contenedores es el punto de partida práctico para la mayoría de los equipos. Arranca en segundos, se integra de forma nativa con pipelines CI/CD y cubre los equipos modernos de campus y centros de datos usados en la mayoría de los casos de uso de automatización. La inversión en construir este entorno se recupera en el primer incidente que previene.

9.2.2.2. Cadena de herramientas para emulación basada en contenedores y VM#

El ecosistema basado en contenedores tiene varias herramientas con roles distintos que a menudo se confunden:

• containerlab instancia y conecta imágenes de OS de red basadas en contenedores. Creado por Roman Dodin y ampliamente adoptado en la comunidad de automatización de redes, containerlab se ha convertido en el estándar de facto para laboratorios de red basados en contenedores. Orquesta directamente contenedores Docker (Arista cEOS, FRR, SONiC, VyOS y otros) y los conecta con enlaces virtuales definidos en un fichero de topología. containerlab arranca la topología y proporciona un laboratorio en funcionamiento en segundos. A medida que los equipos escalan, ejecutar containerlab en una sola máquina se convierte en un cuello de botella. clabernetes distribuye topologías de containerlab en un clúster Kubernetes, permitiendo múltiples ejecuciones de simulación en paralelo y permitiendo a los equipos escalar su puerta de pre-producción a medida que la plataforma crece. Un fichero de topología mínimo de tres nodos se ve así:

name: building-b-sim
topology:
  nodes:
    cisco-1:
      kind: ceos
      image: ceos:17.9.4
    arista-1:
      kind: ceos
      image: ceos:4.31.2F
    hpe-1:
      kind: vr-aoscx
      image: vrnetlab/vr-aoscx:10.12.1006
  links:
    - endpoints: ["cisco-1:eth1", "arista-1:eth1"]
    - endpoints: ["arista-1:eth2", "hpe-1:eth1"]

• netlab abstrae la definición de topología por encima de containerlab. Creado por Ivan Pepelnjak, netlab permite al ingeniero describir qué debe lograr la topología en lugar de cómo conectarla: “estos tres nodos ejecutan BGP”, “estos nodos están en la misma VLAN”. netlab interpreta esa descripción y la renderiza en un fichero de topología de containerlab más configuraciones iniciales de dispositivos por proveedor. Se puede pensar como una descripción declarativa del laboratorio: el ingeniero define el servicio; netlab genera la definición de infraestructura. Cuando el objetivo es probar la lógica de automatización contra una topología que refleja un modelo de red de producción, netlab es el punto de partida correcto; containerlab es lo que la instancia. Una topología netlab mínima para el mismo escenario de tres nodos:

nodes:
  cisco-1:
    device: iosxe
    image: ceos:17.9.4
  arista-1:
    device: eos
  hpe-1:
    device: aoscx

links:
  - cisco-1:
    arista-1:
  - arista-1:
    hpe-1:

vlans:
  app-payments:
    id: 210
    links: [ cisco-1, arista-1, hpe-1 ]

• vrnetlab hace de puente entre la emulación basada en contenedores y la basada en VM. Algunos proveedores no proporcionan imágenes nativas de contenedor. vrnetlab envuelve imágenes de VM de proveedor dentro de contenedores, haciéndolas utilizables dentro de una topología de containerlab. Así es como se puede probar contra un dispositivo Cisco IOS-XR o Junos en un entorno de containerlab sin cambiar a una plataforma basada en VM.

• EVE-NG y GNS3 son plataformas de emulación basadas en VM que proporcionan amplia cobertura de proveedores, diseño de topología con GUI y comportamiento completo del NOS incluyendo reenvío en el plano de datos. La contrapartida: mayor uso de recursos, arranque más lento y limitada integración con CI/CD. Estas son la elección correcta para pruebas de protocolo y diseño, plataformas legacy y escenarios de interoperabilidad multi-proveedor.

• Cisco Modeling Labs es la plataforma de laboratorio VM comercial de Cisco con una API REST para integración parcial con CI/CD. La elección correcta para entornos centrados en Cisco que necesitan acceso a VMs IOS-XE, IOS-XR y NX-OS en un laboratorio compartido y gestionado.

9.2.2.3. Frameworks de validación#

Validar que un dispositivo soporta correctamente un protocolo de interfaz dado o una ruta YANG es parte del trabajo descrito en el Capítulo 5 (Ejecución) y el Capítulo 6 (Observabilidad): el capítulo de Ejecución cubre la validación de las interfaces de configuración antes de depender de ellas en flujos de trabajo de producción; el capítulo de Observabilidad cubre la validación de los caminos de recopilación y la confirmación de que las suscripciones devuelven datos en el formato esperado.

Un escenario merece un tratamiento específico en el contexto de la simulación: la validación por oleadas. Después de que la simulación pasa pero antes de comprometerse con el alcance completo de producción, algunos equipos ejecutan una pasada de validación estructurada contra la primera oleada. pyATS proporciona un framework de pruebas para escribir pruebas estructuradas de interacción con dispositivos con análisis enriquecido y comparación de estados. Robot Framework es un framework de automatización de pruebas más amplio basado en palabras clave con bibliotecas específicas para redes. Ambos permiten a un equipo codificar el estado post-cambio esperado como aserciones ejecutables: después de que VLAN 210 se despliega en la Oleada 1, confirmar que VLAN 210 existe en todos los switches, confirmar que las asociaciones de interfaces son correctas y confirmar que la capa de Observabilidad ve el estado esperado. Esto conecta directamente con la sección 9.2.2.4: la capa de validación estructurada que separa una ejecución de simulación exitosa de la confianza operativa genuina antes de proceder a la siguiente oleada.

Una prueba pyATS mínima que verifica la presencia de VLAN tras el despliegue:

from pyats import aetest

class VlanValidation(aetest.Testcase):
    @aetest.test
    def verify_vlan_exists(self, device):
        output = device.parse('show vlan brief')
        assert 210 in output['vlans'], f"VLAN 210 missing on {device.name}"

    @aetest.test
    def verify_vlan_name(self, device):
        output = device.parse('show vlan brief')
        assert output['vlans'][210]['name'] == 'app-payments'

La misma comprobación en Robot Framework usando la biblioteca NAPALM, con configuración explícita y nombres de palabras clave legibles:

*** Settings ***
Library    Collections
Library    napalm    WITH NAME    NAPALM

*** Variables ***
@{DEVICES}    cisco-1    arista-1    hpe-1

*** Test Cases ***
VLAN 210 Is Present On All Switches After Deployment
    FOR    ${hostname}    IN    @{DEVICES}
        Connect And Check VLAN    ${hostname}    210    app-payments
    END

*** Keywords ***
Connect And Check VLAN
    [Arguments]    ${hostname}    ${vlan_id}    ${vlan_name}
    NAPALM.Open    ${hostname}
    ${vlans}=    NAPALM.Get VLANs
    Dictionary Should Contain Key    ${vlans}    ${vlan_id}
    Should Be Equal    ${vlans}[${vlan_id}][name]    ${vlan_name}
    [Teardown]    NAPALM.Close

9.2.2.4. La simulación como puerta Saga pre-producción#

El Capítulo 7 describió el patrón Saga: un flujo de trabajo de múltiples pasos donde cada paso tiene una acción de compensación correspondiente que se ejecuta si un paso posterior falla. El Saga gestiona los fallos en producción. La simulación añade el paso antes de que comience el Saga: ejecutar el flujo de trabajo contra un entorno de simulación primero. Si la ejecución de simulación falla, no ocurre ningún cambio en producción. Solo cuando la simulación pasa el flujo de trabajo procede al objetivo de producción.

flowchart LR
    SoT["Exportación del SoT (topología + versiones OS)"]
    Lab["Entorno de simulación (topología containerlab)"]
    Workflow["Ejecución del flujo de trabajo (mismo código que producción)"]
    Pass{¿Pasa?}
    Prod["Ejecución en producción (Orquestador: alcance completo)"]
    Fix["Investigar y corregir (sin impacto en producción)"]

    SoT --> Lab --> Workflow --> Pass
    Pass -- Sí --> Prod
    Pass -- No --> Fix --> Workflow

Esta es la puerta pre-producción: la simulación como primera comprobación antes de que comience el alcance del Saga de producción. Un fallo en la simulación se detecta antes de que se toque ningún dispositivo de producción.

Implementación práctica:

1. La Fuente de Verdad exporta la definición de topología para el alcance objetivo, incluyendo las versiones de OS por dispositivo.
2. El entorno de simulación se instancia con imágenes de proveedor coincidentes, con versiones de OS fijadas para que coincidan con el estado previsto de la SoT.
3. El mismo flujo de trabajo que correrá en producción se ejecuta primero contra el objetivo de simulación.
4. Cualquier paso que falla en la simulación desencadena una investigación antes de que proceda la ejecución en producción.

Oleadas de despliegue progresivo

Que la simulación pase no significa desplegar en todo el alcance de producción de una vez. Para despliegues a gran escala, la simulación es la primera puerta en una serie de oleadas progresivamente más grandes, cada una con su propia comprobación de validación antes de que proceda la siguiente oleada. Es uno de los patrones favoritos para ganar confianza en los despliegues críticos, similar al popular patrón Canary del desarrollo de software.

Un equipo que despliega un nuevo flujo de trabajo en 100 centros de datos podría estructurarlo así: simulación (topología virtual) -> 1 sede piloto -> 2 sedes -> 4 -> 8 -> 16 -> sedes restantes. Cada oleada valida que el flujo de trabajo se comportó correctamente en la oleada anterior antes de expandirse. Si la oleada 4 detecta un fallo que la simulación no capturó (un comportamiento específico del hardware, un estado específico de la sede), el despliegue se detiene, el problema se corrige y la secuencia de oleadas se reanuda desde el punto de fallo.

flowchart LR
    Sim["Simulación"] --> W1["Oleada 1 (1 sede)"] --> W2["Oleada 2 (2 sedes)"] --> W3["Oleada 3 (4 sedes)"] --> W4["Oleada N (alcance completo)"]
    W1 -- Fallo --> Fix["Investigar + corregir"]
    W2 -- Fallo --> Fix
    W3 -- Fallo --> Fix
    Fix --> Sim

El Orquestador controla la progresión de oleadas. La SoT delimita cada oleada por sede, edificio o grupo de dispositivos. Las puertas de validación entre oleadas son pasos explícitos del flujo de trabajo: el Orquestador comprueba la capa de Observabilidad para verificar el estado esperado antes de proceder. Este patrón se aplica tanto si el alcance son 100 centros de datos como 800 switches de campus: el principio es limitar el radio de impacto de cualquier fallo imprevisto mientras se construye confianza con cada oleada exitosa.

Limitaciones de la simulación: las imágenes de contenedor no reproducen todos los comportamientos del firmware. Una imagen de contenedor típicamente corre código NOS reciente; las peculiaridades específicas de firmware más antiguo pueden no ser reproducibles a menos que la imagen esté fijada a una versión específica. La simulación detecta errores lógicos, violaciones de contratos de interfaz, lagunas en los modelos Yet Another Next Generation (YANG) y fallos a nivel de topología. No garantiza que se haya probado cada posible estado del dispositivo encontrado en producción. El objetivo es una reducción significativa del riesgo, no cero riesgo.

El problema del snowflake: la simulación es más fiable cuando la red de producción sigue patrones de arquitectura consistentes. Una red con cientos de configuraciones individualmente personalizadas, cada una con estado e historial únicos, es más difícil de representar con precisión en la simulación. Esta es una de las razones por las que los principios de arquitectura de automatización (patrones de diseño estandarizados, plantillas golden, configuración dirigida por la SoT) hacen las pruebas más eficaces: una red bien diseñada es más simulable. El valor de la simulación se multiplica con la calidad del diseño de red que representa. Construir esta repetibilidad requiere una estrecha colaboración con los ingenieros de red, no solo con los ingenieros de automatización: el ingeniero de red que entiende qué sedes son verdaderamente idénticas y cuáles llevan excepciones ocultas es quien puede hacer la simulación representativa. La calidad de la simulación es una salida conjunta de la disciplina de diseño de red y la plataforma de automatización.

9.2.3. Estrategias de Abstracción#

La red es heterogénea por naturaleza, y no solo en el sentido de que los proveedores difieren. Cualquier plataforma de automatización operando a escala abarca simultáneamente switching físico, infraestructura cloud, controladores overlay, infraestructura WAN de proveedores de servicios y equipos legacy. Cada uno habla un idioma diferente. La plataforma de automatización no debe reconstruirse cada vez que se añade un nuevo tipo de infraestructura.

Esta sección trata de diseñar la capa de automatización para absorber el cambio en lugar de romperse bajo él: no solo gestionar la heterogeneidad actual sino diseñar para los tipos de infraestructura que se añadirán el próximo año.

Las plataformas de automatización modernas abarcan múltiples dominios de infraestructura simultáneamente. La arquitectura que gestiona esto limpiamente se aplica tanto si el operador es una gran empresa, un proveedor de servicios que gestiona WAN y edge de cliente simultáneamente, o un hyperscaler que ejecuta fabric de centros de datos junto con overlays de redes cloud. El punto clave: el Ejecutor escribe y el Colector lee a través de la misma interfaz de dispositivo (gRPC Network Management Interface (gNMI)/NETCONF para equipos físicos, REST para cloud y controladores), por lo que el protocolo de interfaz es una preocupación compartida para ambos bloques, no una elección de diseño separada por bloque.

flowchart LR
    SoT["Fuente de Verdad"]
    Orch["Orquestador"]
    Obs["Observabilidad"]

    subgraph Physical["Dominio físico"]
        PhysIF["Interfaz de red (NETCONF/gNMI)"]
        PhysNet["Campus, fabric DC, equipo WAN"]
        PhysIF --- PhysNet
    end

    subgraph Cloud["Dominio cloud"]
        CloudIF["Interfaz de red (REST asíncrono)"]
        CloudNet["VPCs cloud / redes cloud"]
        CloudIF --- CloudNet
    end

    subgraph Overlay["Dominio overlay"]
        OvIF["Interfaz de red (API del controlador)"]
        OvNet["SD-WAN / MPLS PCE / overlay"]
        OvIF --- OvNet
    end

    SoT --> Orch
    Orch -->|Escritura Ejecutor| PhysIF
    Orch -->|Escritura Ejecutor| CloudIF
    Orch -->|Escritura Ejecutor| OvIF
    PhysIF -->|Lectura Colector| Obs
    CloudIF -->|Lectura Colector| Obs
    OvIF -->|Lectura Colector| Obs

La Fuente de Verdad modela la intención completa en todos los tipos de topología como un modelo de servicio unificado. El Orchestrator contiene bifurcaciones por dominio de red. El Ejecutor enruta al adaptador correcto basándose en los datos de la SoT. La Observabilidad abarca todas las capas, alimentando el mismo pipeline de datos independientemente del tipo de infraestructura subyacente.

La disciplina arquitectónica clave: la bifurcación ocurre en el Ejecutor y el Orquestador, no en la SoT. La SoT mantiene un único modelo de intención para el servicio. Cómo se realiza esa intención en distintos tipos de infraestructura es una preocupación del Ejecutor.

9.2.3.1. Dimensiones de la heterogeneidad#

Antes de elegir una estrategia de abstracción, es útil entender el eje de heterogeneidad que esa estrategia debe absorber. No toda la heterogeneidad es el mismo tipo de problema.

Cada fila es un eje de diferencia que la plataforma debe gestionar sin requerir que la SoT lo codifique. El modelo de intención permanece unificado; el Ejecutor y el Orquestador absorben la variación. Las estrategias de las siguientes secciones abordan cómo.

9.2.3.2. Patrón adaptador en el Ejecutor y el Colector#

El punto de partida más común y la estrategia más ampliamente implementada. Un módulo de automatización por proveedor, todos aceptando la misma estructura de datos de entrada de la SoT. La SoT almacena la intención neutral al proveedor; la capa de adaptador del Ejecutor traduce por proveedor en el momento de la ejecución. El mismo principio se aplica al Colector: un módulo de recopilación por proveedor o protocolo, todos entregando una estructura de datos normalizada al pipeline de Observabilidad. Un proveedor que habla gNMI usa un adaptador; un proveedor que requiere sondeo SNMP o REST propietario usa otro. La capa de Observabilidad ve el mismo esquema de datos independientemente del método de recopilación upstream.

flowchart LR
    SoT["Intención del SoT (neutral al proveedor): vlan_id=210, vlan_name=app-payments"]
    Exec["Ejecutor"]
    CiscoA["Adaptador Cisco: IOS-XE NETCONF"]
    AristaA["Adaptador Arista: eAPI / EOS"]
    HPEA["Adaptador HPE: NETCONF + gestión errores versión OS"]
    CiscoD["Cisco Catalyst"]
    AristaD["Arista 7050"]
    HPED["HPE Aruba 6300"]

    CollGNMI["Colector: adaptador gNMI"]
    CollSNMP["Colector: adaptador SNMP"]
    Obs["Pipeline de Observabilidad (esquema normalizado)"]

    SoT --> Exec
    Exec --> CiscoA --> CiscoD
    Exec --> AristaA --> AristaD
    Exec --> HPEA --> HPED

    CiscoD --> CollGNMI --> Obs
    AristaD --> CollGNMI
    HPED --> CollSNMP --> Obs

Práctico de construir y bien comprendido. La carga de mantenimiento crece a medida que el inventario de dispositivos se diversifica: cada nuevo proveedor o versión de OS requiere un adaptador nuevo o actualizado. El patrón adaptador escala bien para un conjunto definido de proveedores; se vuelve pesado cuando la plataforma debe soportar un catálogo de dispositivos grande y que cambia frecuentemente.

9.2.3.3. Modelos YANG impulsados por la comunidad y la industria#

Dos organismos industriales publican los modelos YANG neutrales al proveedor que reducen el trabajo de adaptador por proveedor. Los modelos IETF (publicados como RFCs e Internet-Drafts) definen estructuras de datos fundamentales: ietf-interfaces, ietf-routing, ietf-bgp. Los modelos OpenConfig, desarrollados por un consorcio de operadores (Google, AT&T, Deutsche Telekom y otros), cubren territorio similar con un esquema más enfocado a las operaciones y un ciclo de iteración más rápido. Ambos permiten a la plataforma de automatización escribir la intención una vez contra un modelo estándar y esperar que funcione en cualquier dispositivo compatible.

Un módulo YANG que define una interfaz se ve así (simplificado de ietf-interfaces):

module ietf-interfaces {
  container interfaces {
    list interface {
      key "name";
      leaf name      { type string; }
      leaf description { type string; }
      leaf enabled   { type boolean; default true; }
    }
  }
}

La misma estructura aparece en OpenConfig (openconfig-interfaces) y en los modelos nativos del proveedor, pero con diferentes rutas, diferentes nombres de hoja y diferentes semánticas predeterminadas. El módulo YANG define el esquema; el protocolo (NETCONF o gNMI) transporta los datos; la capa de adaptador hace la correspondencia entre el estándar y la realidad del proveedor.

La realidad práctica de OpenConfig: las implementaciones de los proveedores varían en completitud. Un dispositivo puede declarar soporte OpenConfig pero solo implementar un subconjunto del modelo: las lecturas funcionan, las escrituras no; o el modelo de interfaz funciona pero el modelo BGP está ausente.

Más allá de las rutas que faltan, el problema más insidioso son los datos inconsistentes. Un dispositivo devuelve un valor para una ruta OpenConfig pero en la unidad incorrecta, con un tipo diferente o con campos que deberían ser nulos poblados con valores predeterminados específicos del proveedor. Una suscripción gRPC Network Management Interface (gNMI) que funciona en modo SAMPLE puede fallar silenciosamente en modo ON_CHANGE en el mismo dispositivo.

Estos no son casos extremos raros. Son la realidad cotidiana de operar una plataforma multi-proveedor que se basa en OpenConfig en producción. El estándar funciona en papel; la implementación del proveedor requiere la misma investigación por dispositivo que el estándar pretendía eliminar. OpenConfig reduce ese trabajo significativamente, pero no lo elimina. Hay que planificar pruebas específicas del dispositivo antes de depender de una nueva ruta OpenConfig en la automatización de producción.

Una nota sobre las familias de modelos YANG

Tres familias de modelos Yet Another Next Generation (YANG) coexisten en las redes de producción, y entender la distinción importa para elegir a cuál apuntar:

• Los modelos IETF se desarrollan a través del proceso de estándares IETF y se publican como RFCs o Internet-Drafts. Son los estándares fundamentales: ietf-interfaces, ietf-routing, ietf-bgp. La adopción es amplia pero lenta; el proceso es minucioso pero lleva años. Las implementaciones de los proveedores a menudo llegan dos a cuatro años después de la publicación.
• Los modelos OpenConfig son desarrollados por el consorcio OpenConfig, un grupo dirigido por operadores (Google, AT&T, Deutsche Telekom y otros). OpenConfig itera más rápido que IETF y está más enfocado a las operaciones. Cubre muchas de las mismas áreas funcionales que los modelos IETF pero con diferentes elecciones de diseño del esquema. La mayoría de los despliegues gNMI en producción usan rutas OpenConfig.
• Los modelos nativos del proveedor son las extensiones propias de cada proveedor: cisco-ios-xe-native, junos-conf-root, arista-eos-augments. Estos exponen características que los modelos estándar no cubren, y a menudo son necesarios para cualquier cosa más allá de las funciones de mínimo común denominador que abordan IETF y OpenConfig. Nokia es un caso extremo: casi todos los datos operativos en SR OS solo son accesibles a través de modelos YANG específicos de Nokia (nokia-conf, nokia-state). Los modelos estándar cubren una superficie delgada; los modelos nativos del proveedor son obligatorios para cualquier automatización significativa en esa plataforma.

La abstracción compra uniformidad a costa del acceso a características. Cada proveedor tiene capacidades propietarias sin equivalente en los modelos estándar. Un equipo que usa OpenConfig debe elegir: ignorar la característica, añadir una extensión del proveedor o mantener un camino de override específico del proveedor. No hay una respuesta limpia. En la práctica, la mayor parte del trabajo de automatización se concentra en funciones bien cubiertas por los modelos estándar (VLANs, BGP, interfaces); las características propietarias importan pero raramente son el caso de uso central. Los estándares también llegan con retraso en la adopción: un proveedor puede implementar un módulo IETF dos a cuatro años después de la publicación, y solo en plataformas más nuevas. Hay que condicionar el uso de características a la versión de OS registrada en la SoT en lugar de asumir soporte uniforme.

9.2.3.4. SONiC y open networking#

La interfaz de configuración de SONiC es una base de datos Redis con un esquema estructurado según YANG: uniforme, programática y diseñada para la automatización desde el principio. El trabajo de adaptador específico del proveedor que consume esfuerzo en entornos físicos multi-proveedor no se aplica aquí. La misma lógica de automatización funciona en todas las plataformas basadas en SONiC independientemente del proveedor de hardware subyacente.

Una entrada VLAN en el CONFIG_DB de SONiC se ve así:

{
  "VLAN": {
    "Vlan210": {
      "vlanid": "210"
    }
  },
  "VLAN_MEMBER": {
    "Vlan210|Ethernet0": {
      "tagging_mode": "untagged"
    }
  }
}

Este JSON se escribe directamente en Redis vía sonic-cfggen o la API REST de gestión de SONiC. No hay CLI que analizar, no hay XML que construir. La plataforma de automatización escribe datos estructurados; el orchagent de SONiC los reconcilia con las tablas de reenvío del hardware.

Esta es la dirección de diseño que defiende el open networking: una interfaz de red diseñada para la automatización en lugar de adaptada a ella. Los equipos que introducen plataformas basadas en SONiC junto con equipos tradicionales encontrarán que el adaptador SONiC es el más simple de escribir y el más fiable de operar.

• Ofertas de proveedores: SONiC ha avanzado mucho más allá de sus orígenes en Microsoft Azure. La mayoría de los grandes proveedores de silicon de switches ahora ofrecen plataformas basadas en SONiC: Microsoft Azure SONiC (la referencia upstream), Arista con APIs de gestión compatibles con SONiC en plataformas seleccionadas, la serie Cisco 8000 con soporte SONiC basado en Broadcom, Dell OS10 (que usa una arquitectura derivada de SONiC), las plataformas Nvidia Spectrum con SONiC como opción de primera clase, y un número creciente de proveedores ODM (Edgecore, Celestica, UfiSpace) que ofrecen plataformas SONiC de marca. El ecosistema ha madurado hasta el punto de que una plataforma basada en SONiC está disponible comercialmente en cada nivel de precio y rendimiento.

• Casos de uso maduros: los fabrics leaf-spine de centros de datos son el despliegue más establecido. Los hyperscalers han ejecutado SONiC a escala durante más de una década; los centros de datos empresariales ahora los siguen. El overlay EVPN/VXLAN, el enrutamiento BGP, el balanceo de carga ECMP y el soporte de interfaces 400G/800G están bien validados. La historia de automatización es sólida: gNMI, YANG y el CONFIG_DB respaldado por Redis son interfaces nativas. Una flota SONiC puede gestionarse con las mismas herramientas que gestionan cualquier otra plataforma habilitada para gNMI.

• Nuevas fronteras: SONiC está comenzando a aparecer fuera del fabric DC tradicional. Las plataformas de enrutamiento disaggregated (donde SONiC corre en routers de alto número de puertos en lugar de solo switches) extienden el modelo de NOS abierto a casos de uso de enrutamiento. SONiC ahora incluye soporte de segment routing: SRv6 (Segment Routing sobre IPv6) está disponible en SONiC upstream y lo están usando en producción proveedores de servicios que ejecutan plataformas basadas en SONiC para ingeniería de tráfico y network slicing. Algunos proveedores de servicios también están evaluando SONiC para peering edge y agregación de banda ancha. Los despliegues de SONiC en campus siguen siendo raros pero son técnicamente factibles; el ecosistema de hardware para factores de forma de campus es menos maduro. Para los equipos que construyen nuevas plataformas hoy en día, la pregunta ya no es si SONiC está listo para producción en el DC: lo está. La pregunta abierta es si el fork SONiC del proveedor y el ciclo de releases permanecerán alineados con upstream durante el ciclo de vida de la plataforma.

9.2.3.5. Gestión de la coexistencia durante la migración de firmware#

El patrón adaptador asume una versión de OS conocida y estable por dispositivo. Durante una actualización de firmware progresiva, esa suposición se rompe: los dispositivos del mismo rol, gestionados por la misma plataforma de automatización, corren diferentes versiones de OS simultáneamente durante días o semanas. La capa de abstracción que funcionaba ayer en el firmware 10.12 puede no funcionar en el firmware 10.13 hasta que se añade un nuevo camino de adaptador.

La SoT debe registrar la versión de OS prevista (el objetivo después de la migración) y el Colector debe mostrar la versión de OS actual como estado operativo. Antes de que el Ejecutor aplique la configuración, debe leer la versión de OS actual del Colector o del pipeline de Observabilidad y seleccionar el camino de adaptador apropiado, no asumir que la versión prevista ya está desplegada.

Un mecanismo concreto: el Ejecutor consulta el bloque de Observabilidad (o una comprobación previa a la ejecución ligera contra el propio dispositivo) para la versión de OS en ejecución. El registro de adaptadores mapea rangos de versiones de OS a implementaciones de adaptadores. El Ejecutor invoca el adaptador correcto basándose en el estado actual, no en la intención de la SoT. Una vez que un dispositivo está actualizado y la versión en ejecución coincide con la intención, la selección del adaptador se estabiliza. Durante la ventana de migración, dos caminos de adaptador para el mismo proveedor pueden estar activos simultáneamente.

El ejemplo de implementación de la sección 9.3 demuestra este patrón directamente: el bug del adaptador HPE fue disparado porque una versión de firmware devolvía vlan-exists y otra devolvía duplicate-vlan para la misma condición. La corrección fue el manejo de errores por versión de OS en el registro de adaptadores. Cualquier plataforma de automatización que gestione una flota multi-versión se encontrará con esta clase de problema. Codificar la lógica del adaptador por versión, impulsada por la versión de OS actual leída del Colector, es la mitigación sistemática. El Capítulo 11 aborda cómo mantener los mapeos de versiones de OS como un catálogo a nivel de plataforma en lugar de como constantes por playbook.

La implicación organizacional: alguien debe ser responsable del seguimiento de versiones de OS en la SoT, el registro de versiones de adaptador y el flujo de trabajo de secuenciación de actualizaciones. Estos tres artefactos forman el sistema de automatización de actualizaciones. Sin una titularidad explícita, derivan de forma independiente y la fiabilidad de la plataforma se degrada con cada release de firmware.

9.2.4. La Red como Restricción de Cada Bloque#

Las tres áreas cubiertas en esta sección, interfaces programables, entornos de simulación y estrategias de abstracción, no son temas aislados. Describen la influencia de la red sobre cada bloque del framework NAF.

Las capacidades de interfaz de la red restringen lo que puede hacer el Ejecutor: un dispositivo que solo soporta CLI obliga al adaptador del Ejecutor a un frágil screen scraping; un dispositivo con soporte maduro de gNMI habilita configuración fiable y telemetría en streaming. El soporte de recopilación de la red restringe lo que puede ingerir el Colector: un dispositivo que no implementa una ruta OpenConfig necesaria requiere una solución específica del proveedor o una laguna en la recopilación. La topología de la red restringe lo que el Orquestador puede paralelizar de forma segura: un tamaño de lote que es seguro para una capa de acceso plana puede ser catastrófico para un fabric spine-leaf donde los cambios simultáneos a múltiples nodos spine pueden particionar la red.

El modelo de datos de la SoT refleja estas restricciones. Los campos de versión de OS controlan la selección del adaptador. Los campos de tipo de interfaz controlan el método de recopilación. Las relaciones de topología controlan las reglas de concurrencia del Orquestador. Una SoT que registra el inventario de dispositivos sin registrar los atributos relevantes para la automatización (capacidades de interfaz, versión de OS, rol en la topología) está incompleta de maneras que solo se revelan en el momento de la ejecución.

Cada decisión arquitectónica de la Parte 2 tiene una restricción correspondiente a nivel de red que este capítulo expone. La red no es solo el objetivo de la automatización. Da forma a cada bloque que actúa sobre ella, y esas restricciones deben codificarse en el modelo de datos de la plataforma, la lógica del adaptador y la configuración del flujo de trabajo. La automatización que trata la red como una superficie uniforme descubrirá la heterogeneidad un despliegue fallido a la vez.

9.3. Ejemplo de Implementación#

9.3.1. De la Simulación a la Producción#

El flujo de trabajo VLAN del campus está listo. Ocho semanas de desarrollo, tres proveedores modelados, idempotencia probada contra un laboratorio de tres nodos. El equipo quiere desplegarlo en producción: 800 switches, edificios A hasta F. Antes de eso, lo ejecutan contra la simulación.

Este ejemplo sigue la secuencia de la puerta pre-producción descrita en la sección 9.2.2.4, usando el alcance del Edificio B como objetivo de simulación: 24 switches, 8 Cisco, 8 Arista, 8 HPE.

Paso 1: Exportar la topología de la Fuente de Verdad

La SoT contiene el inventario de switches del Edificio B con las versiones de OS previstas:

• 8 Cisco Catalyst 9300: IOS-XE 17.9.4
• 8 Arista 7050: EOS 4.31.2F
• 8 HPE Aruba 6300: AOS-CX 10.12.1006 (línea de firmware más antigua, pre-10.13)

La exportación de la SoT produce una definición de topología netlab: tipos de nodo, etiquetas de imagen específicas del proveedor mapeadas a versiones de OS previstas, y el estado de VLAN con el que debe empezar la simulación (VLANs existentes 100, 150 y 200 ya configuradas en todos los switches, coincidiendo con el estado de producción).

Paso 2: Instanciar el entorno de simulación

netlab renderiza la exportación de la SoT en un fichero de topología de containerlab. containerlab corre en un host Linux de simulación compartido en el entorno CI del equipo (un servidor bare-metal con 64 GB de RAM, suficiente para 24 contenedores cEOS/vrnetlab ligeros simultáneamente). Los nodos HPE usan una imagen AOS-CX envuelta por vrnetlab fijada a 10.12.1006, coincidiendo con la versión de OS prevista de la SoT. containerlab arranca la topología. Los 24 nodos están activos y responden a NETCONF y gRPC Network Management Interface (gNMI) en noventa segundos.

Paso 3: Ejecutar el flujo de trabajo VLAN del Capítulo 7 contra el objetivo de simulación

El Orquestador dispara el flujo de trabajo con el inventario de simulación como alcance objetivo en lugar del inventario de producción. Los primeros cuatro pasos del flujo de trabajo se completan sin problemas:

• Webhook de ServiceNow recibido, analizado, validado contra el esquema de la SoT
• Pre-comprobación: VLAN 210 no existe en la simulación (correcto)
• SoT actualizada con la intención de VLAN 210
• Puerta de aprobación: auto-aprobada en modo simulación

El quinto paso del flujo de trabajo, la ejecución en fan-out en los 24 switches simulados vía el Ejecutor, devuelve fallos.

Resultados: 8 nodos Cisco pasan. 8 nodos Arista pasan. 8 nodos HPE fallan.

Error de los nodos HPE: vlan-exists. La comprobación de idempotencia en el adaptador HPE manejaba duplicate-vlan como un no-op pero no tenía manejador para vlan-exists. El Ejecutor devolvió fallo, disparando la compensación del Saga: VLAN 210 eliminada de todos los nodos que la habían recibido.

No ha ocurrido ningún cambio en producción. El coste del fallo es el tiempo de arranque del contenedor y treinta minutos de investigación.

Paso 4: Diagnosticar y corregir

El equipo revisa las notas de release de AOS-CX 10.12. El error vlan-exists fue introducido en 10.11.1, reemplazando duplicate-vlan para la detección de VLAN duplicada. La release 10.13 revirtió a duplicate-vlan por consistencia con el resto de la línea de productos Aruba.

Corrección: añadir vlan-exists a la lista de códigos de error idempotentes en el adaptador HPE. La SoT se actualiza con una nota sobre el límite de la versión de OS (10.11 hasta 10.12.x devuelve vlan-exists; 10.13+ devuelve duplicate-vlan).

Antes de volver a ejecutar, el equipo codifica el estado post-cambio esperado como una prueba pyATS o Robot Framework: después de que el flujo de trabajo se complete, verificar que VLAN 210 existe en los 24 nodos de simulación y que no se disparó la compensación del Saga. Esta aserción se añade a los criterios de paso de la simulación: la puerta de simulación solo se cierra cuando tanto el flujo de trabajo se completa como las aserciones de validación pasan.

Paso 5: Volver a ejecutar en simulación

El adaptador corregido se ejecuta contra la misma topología de containerlab. Los 24 nodos pasan. El Saga se completa sin compensación. La SoT muestra VLAN 210 presente en todos los nodos del Edificio B.

Paso 6: Despliegue en producción

El Orquestador dispara el mismo flujo de trabajo contra el alcance completo de producción: 800 switches, edificios A hasta F. Cada paso corre a través del mismo patrón Saga validado en simulación. Cero fallos en nodos HPE. El ticket de ServiceNow del equipo de aplicaciones se cierra automáticamente cuando el Orquestador completa. La capa de Observabilidad valida la presencia de VLAN 210 en todas las interfaces dentro de la ventana de tiempo esperada.

Qué demuestra esto

El entorno de simulación no es un paso de verificación que se puede omitir cuando el equipo se siente seguro. Es la puerta pre-producción en el patrón Saga. Una topología de simulación que refleja la topología de producción y las versiones de OS es el entorno de pruebas mínimo viable para un equipo que despliega automatización a escala de campus. La inversión es la configuración de containerlab, las imágenes fijadas a versiones de OS y un mecanismo de exportación de la SoT. El retorno es la capacidad de detectar bugs específicos del dispositivo antes de que se conviertan en incidentes.

La simulación detectó este bug no por pruebas exóticas, sino porque la versión de OS en la simulación coincidía con producción y la plataforma ejecutó exactamente el mismo código de flujo de trabajo contra ella. La fidelidad del entorno de simulación al estado de producción es lo que hace posible la detección. Un entorno de simulación que corre las últimas imágenes del proveedor lo habría perdido.

El Capítulo 10 cubre cómo operacionalizar los entornos de simulación como parte de la plataforma: manteniendo las topologías de containerlab en control de versiones, sincronizándolas con exportaciones de la SoT de forma programada e integrándolas en pipelines CI/CD para que la puerta de simulación se ejecute automáticamente en cada cambio de flujo de trabajo.

9.4. Resumen#

El Capítulo 9 cierra la Parte 2 abordando el bloque al que siempre apuntaba la plataforma de automatización: la propia red.

Tres ideas anclan el capítulo.

La red no es uniforme. Cualquier plataforma de automatización a gran escala interactúa simultáneamente con switching de campus, fabric de centros de datos, VPCs en la nube, overlays de Kubernetes, controladores overlay y equipos legacy. Cada uno expone una interfaz diferente, opera bajo diferentes semánticas de consistencia y tiene diferente madurez en automatización. La plataforma absorbe esta heterogeneidad a través de la jerarquía de selección de interfaces (gRPC Network Management Interface (gNMI) para telemetría, NETCONF para configuración, Command Line Interface (CLI) como último recurso), el seguimiento de versiones de OS en la Fuente de Verdad y los adaptadores específicos del proveedor en el Ejecutor.

Los entornos de simulación son la puerta pre-producción. La emulación basada en contenedores proporciona entornos realistas, rápidos e integrados con CI/CD donde la lógica de automatización se prueba contra la topología y las versiones de OS que reflejan la producción. Los fallos en simulación son baratos. Los fallos en producción son caros. La fidelidad del entorno de simulación al estado de producción es lo que hace significativa la puerta.

Las estrategias de abstracción extienden la vida útil de la plataforma. El patrón adaptador gestiona el entorno físico multi-proveedor actual. OpenConfig y la traducción YANG empujan hacia modelos neutrales al proveedor que reducen el mantenimiento de adaptadores a largo plazo. SONiC elimina completamente el trabajo de adaptador para las plataformas que lo soportan. Ninguna de estas estrategias proporciona una respuesta perfecta; cada una implica compromisos entre uniformidad y acceso a características. La elección correcta depende del catálogo de dispositivos del equipo, la capacidad operativa y cuánto de su trabajo de automatización cae dentro de la cobertura de características estándar.

Con el Capítulo 9, la Parte 2 está completa. Seis capítulos han cubierto los siete bloques constructivos del framework NAF: Fuente de Verdad, Colector y Observabilidad (juntos en el Capítulo 6), Ejecución, Orquestación, Presentación y La Red. Estos no son herramientas independientes. La SoT alimenta al Ejecutor con la intención que necesita y al Colector con el estado esperado para validar. El Orquestador secuencia ambos, gestiona los fallos y muestra el progreso a la capa de Presentación. La Red se encuentra debajo de todos ellos: la restricción que moldea el diseño de cada otro bloque, y el lugar donde la automatización en última instancia produce un resultado o falla.

La Parte 3 pasa de construir los bloques a operar la plataforma a escala: ingeniería para la fiabilidad, diseño para la seguridad y el cumplimiento, y tratar la plataforma de automatización como un producto con su propio ciclo de vida y requisitos operativos.

Referencias y Lecturas Adicionales#

• Network Programmability and Automation, Matt Oswalt, Christian Adell, Scott Lowe, Jason Edelman (O’Reilly, 2.ª ed. 2023). La guía práctica más completa sobre herramientas de automatización de redes, que cubre NETCONF, gNMI, modelos YANG y frameworks de automatización en profundidad.
• Network Programmability with YANG, Benoit Claise, Loe Clarke, Jan Lindblad (Pearson, 2019). La referencia definitiva sobre el modelado de datos YANG: cómo se estructuran los modelos IETF y OpenConfig, cómo leer y escribir módulos YANG, y cómo los usan NETCONF y RESTCONF.
• Cisco pyATS: Network Test and Automation Solution, John Capobianco, Dan Wade (Cisco Press). Una guía completa de pyATS y Genie para la automatización de pruebas de red: scripts de prueba, parsers, validación estructurada de estado e integración con pipelines CI/CD.
• Infrastructure as Code, Kief Morris (O’Reilly, 2.ª ed. 2021). No es específico de redes, pero fundamental para entender cómo los principios detrás de la infraestructura repetible, testeable y versionada se aplican directamente al diseño de plataformas de automatización de redes.

💬 Found something to improve? Send feedback for this chapter