4. La Fuente de Verdad#

Un nuevo servicio tenía que estar en producción antes de fin de semana. El cambio era sencillo: una nueva VLAN, una nueva subred, reglas de firewall actualizadas y una nueva comunidad BGP en los routers de borde. El ingeniero de red sabía exactamente qué hacer. Lo que siguió fueron cuatro días de coordinación entre cinco sistemas: la herramienta de IPAM para reservar la subred, el CMDB para registrar el servicio, la plataforma de gestión del firewall para aplicar la nueva política, el sistema de configuración de routers para la comunidad BGP y la plataforma de monitorización para añadir los nuevos umbrales. Cada sistema tenía su propia interfaz, su propio modelo de datos y su propio flujo de aprobación. Y como no había una referencia compartida, el ingeniero tuvo que llevar el contexto manualmente: copiando valores de un sistema al siguiente, esperando que nada cambiara entre pasos.

Seis meses después, el servicio fue retirado. La VLAN se eliminó. La subred quedó libre. Pero la regla del firewall se quedó. Nadie recordaba que estaba vinculada a ese servicio. La comunidad BGP persistió en dos routers de borde. El umbral de monitorización siguió generando alertas de baja prioridad que el NOC aprendió a ignorar. Con el tiempo, la red acumuló capas de configuración huérfana: restos de cambios que nunca fueron completamente rastreados, nunca completamente revertidos, nunca conectados a un registro compartido de intención.

Así es como se ve realmente operar una red sin fuente de verdad. No un único fallo dramático, sino una acumulación lenta de inconsistencia, donde cada cambio requiere actualizar múltiples sistemas desconectados y donde nada lleva la cuenta de qué pertenece a qué.

Todo sistema de automatización empieza con una pregunta: ¿Qué voy a hacer exactamente? Cuando despliegas una regla de firewall, añades una dirección IP o configuras una VLAN, lo haces basándote en alguna representación de la intención. Esa representación es tu fuente de verdad: la versión única y fiable de lo que debería desplegarse.

Uso “Fuente de Verdad” e “Intención” de forma intercambiable. Son exactamente el mismo concepto.

Sin una fuente de verdad fiable, las operaciones de red se convierten en un caos de conocimiento tribal. Los ingenieros discrepan sobre lo que está desplegado. Las hojas de cálculo contradicen lo que está realmente en ejecución. Dos sistemas de automatización diferentes realizan cambios contradictorios en el mismo dispositivo. Cuando algo falla, te quedas haciendo arqueología: “¿Por qué estaba configurado así? ¿Quién lo aprobó? ¿Cuándo cambió?”

Este capítulo examina cómo construir una fuente de verdad que funcione tanto si tienes decenas de dispositivos como cientos de miles, que sirva a todos los que necesitan datos (humanos, automatización y otros sistemas), que mantenga los datos precisos y de confianza, y que gestione la complejidad de obtener datos de múltiples fuentes. Cubriremos seis bloques: Modelado, Consumo, Aplicación, Versionado, Agregación y Orientado al Diseño, que juntos crean una base sólida para la automatización de redes.

4.1. Fundamentos#

La fuente de verdad hace tres cosas: define cómo expresas lo que quieres, dónde vive esa intención y cómo mantienes su fiabilidad a lo largo del tiempo. Sin ella, los demás bloques se convierten en herramientas independientes sin referencia compartida. Con ella, trabajan juntos.

4.1.1. Objetivos#

Tu fuente de verdad necesita hacer seis cosas:

1. Capturar todo lo que necesitas. Almacena la imagen completa de tu red: configuraciones, activos, topología, servicios, direcciones IP, circuitos, especificaciones de dispositivos, secretos, ventanas de mantenimiento, cumplimiento y propietarios. Incluye no solo lo que está en producción hoy, sino lo que tienes planificado y lo que estás retirando. Cuando todos estos datos viven en un único lugar en lugar de dispersos entre hojas de cálculo y la memoria de las personas, tus sistemas de automatización tienen el contexto que necesitan para tomar decisiones inteligentes.

2. Permitir a los operadores pensar en términos de negocio, no en sintaxis de dispositivo. El personal debería trabajar a nivel de negocio (“añadir una nueva sucursal” o “configurar un servicio MPLS”) y no a nivel de Command Line Interface (CLI). Entre bastidores, el sistema calcula las configuraciones específicas para cada dispositivo. Esto mantiene a las personas enfocadas en lo que quieren conseguir, no en los detalles de bajo nivel.

3. Permitir que personas y máquinas accedan a los datos fácilmente. El sistema necesita Application Programming Interface (API)s (Representational State Transfer (REST), GraphQL) para que la automatización pueda obtener y modificar datos. Necesita una interfaz web y Command Line Interface (CLI) para que los humanos puedan navegar y editar. Todos necesitan controles de acceso sólidos para que cada uno vea solo lo que debe. Puedes tener cien flujos de trabajo de automatización ejecutándose simultáneamente, decenas de personas editando datos y sistemas externos sincronizando datos, y todo permanece consistente y rápido.

4. Mantener los datos limpios y de confianza. Valida todo: comprueba que los tipos de datos son correctos, que las relaciones tienen sentido, que las VLANs están en rangos válidos, que las direcciones IP no se duplican. Registra quién cambió qué y cuándo. Permite aprobar cambios importantes antes de que se consoliden. Si algo sale mal, puedes revertir. Tu automatización necesita confiar en que los datos son precisos, porque los datos incorrectos llevan a un estado de red incorrecto y a interrupciones.

5. Permitir que las personas trabajen en paralelo sin pisarse. Múltiples equipos deben poder proponer cambios al mismo tiempo. Los cambios se agrupan en paquetes atómicos: o todos se aplican o todos fallan, sin estados intermedios. Puedes probar cambios en un entorno de staging antes de que entren en producción. Para migraciones grandes, puedes ramificar, trabajar y fusionar de vuelta. Siempre sabes qué intención está en uso ahora y cuál está siendo propuesta.

6. Incorporar datos de otros sistemas. Probablemente ya tienes gestión de activos para el hardware, sistemas de IP para las direcciones, proveedores de circuitos para la conectividad y CMDBs para los servicios. No los dupliques. En su lugar, sincroniza con ellos. Establece reglas claras sobre qué sistema es propietario de qué datos. Mantén todo sincronizado en ambas direcciones. Esto significa obtener una vista unificada de todo sin reinventar la rueda.

4.1.2. Pilares#

Estos seis pilares no son funcionalidades independientes; forman una arquitectura en capas. El Modelado define lo que puede expresarse. El Orientado al Diseño traduce esa expresión en artefactos técnicos. El Consumo pone esos artefactos a disposición de todos los sistemas que los necesitan. La Aplicación mantiene los datos fiables en el momento de entrada. El Versionado preserva el registro de intención a lo largo del tiempo, habilitando la reversión y la auditoría. La Agregación evita que el SoT se convierta en otro silo aislado, incorporando datos autorizados de los sistemas que ya los poseen.

Elimina cualquiera de ellos y los demás se degradan. Sin Aplicación, el Consumo sirve datos incorrectos. Sin Versionado, no hay forma de razonar sobre qué cambió cuando algo falla. Sin Agregación, los operadores mantienen datos duplicados en múltiples sistemas y el SoT pierde credibilidad. La sección 4.2 aborda cada uno en profundidad.

4.1.3. Alcance#

En el alcance:

La fuente de verdad gestiona todos los datos de intención: la definición completa de cómo debería verse tu red. Esto incluye configuraciones de producción, entornos de staging, ramas de desarrollo y escenarios de prueba. Todo lo que describe “lo que quieres” vive aquí.

Fuera del alcance:

1. Datos de Observabilidad: La fuente de verdad no almacena métricas, registros ni estado en tiempo de ejecución. Sin embargo, define las expectativas con las que se comparará, como los valores de umbral para alertas o los números de rendimiento base. Los datos de observabilidad reales viven en otro lugar (cubiertos en el Capítulo 6).

2. Interacción con la red: La fuente de verdad no habla con los dispositivos ni aplica configuraciones. Proporciona los artefactos necesarios (configuraciones de dispositivos, reglas de validación, manifiestos de despliegue) pero no los ejecuta. Ese es el trabajo del Ejecutor (Capítulo 5).

3. Lógica de orquestación: La fuente de verdad no define la secuencia de pasos o los flujos de trabajo para desplegar cambios. Define el estado final deseado. Cómo llegar allí (qué dispositivos primero, qué pasos de validación, procedimientos de reversión) pertenece al Orquestador (Capítulo 7).

Piensa en la fuente de verdad como la estrella polar de tu estrategia de automatización de redes. Es la respuesta única y autorizada a “¿cómo debería verse la red?” Todo lo demás en tu sistema de automatización (ejecución, monitorización, orquestación) consulta esta verdad para hacer su trabajo. Cuando la realidad se aleja de la intención, la fuente de verdad te dice en qué debería convertirse la realidad.

4.2. Funcionalidades#

Cada una se corresponde con un objetivo y un pilar:

1. Modelado: Define qué datos almacenas y cómo se relacionan. Modelos de dispositivos, interfaces, VLANs, circuitos, servicios. Que evolucione a medida que cambien tus necesidades.

2. Orientado al Diseño: Traduce la intención de alto nivel en configuraciones reales de dispositivos mediante plantillas y lógica.

3. Consumo: Cómo las personas y los sistemas realmente obtienen y usan los datos. Application Programming Interface (API)s, interfaz web, Command Line Interface (CLI). Todos obtienen el control de acceso adecuado a su rol.

4. Aplicación: Garantiza que los datos incorrectos no se cuelen. Validación, comprobaciones de unicidad, integridad referencial. Mensajes de error claros.

5. Versionado: Mantiene el historial completo. Quién cambió qué, cuándo y por qué. Revertir cuando sea necesario.

6. Agregación: Incorpora datos de otros sistemas (CMDB, IPAM, etc.) y los mantiene sincronizados.

graph LR

    subgraph Goals["Objetivos"]
        direction TB
        A1[Capturar todo lo que necesitas]
        A2[Permitir a los operadores pensar en términos de negocio, no en sintaxis de dispositivo]
        A3[Permitir que personas y máquinas accedan a los datos fácilmente]
        A4[Mantener los datos limpios y fiables]
        A5[Permitir que las personas trabajen en paralelo sin pisarse]
        A6[Incorporar datos de otros sistemas]
    end

    subgraph Pillars["Pilares"]
        direction TB
        B1[Marco flexible de modelado de datos]
        B2[Diseño y plantillas]
        B3[APIs e interfaces]
        B4[Validación de datos]
        B5[Historial de cambios]
        B6[Agregación de datos]
    end

    subgraph Functionalities["Funcionalidades"]
        direction TB
        C1[Modelado]
        C2[Orientado al Diseño]
        C3[Consumo]
        C4[Aplicación]
        C5[Versionado]
        C6[Agregación]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5
    A6 --> B6 --> C6

    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;
    classDef row4 fill:#b3d8ff,stroke:#4a90e2,stroke-width:1px;
    classDef row5 fill:#99ccff,stroke:#4a90e2,stroke-width:1px;
    classDef row6 fill:#80bfff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;
    class A4,B4,C4 row4;
    class A5,B5,C5 row5;
    class A6,B6,C6 row6;

La siguiente es una perspectiva arquitectónica del bloque de Intención:

graph TB

    subgraph T1[Externo]
        A[Consumo]
    end

    subgraph T2[Datos]
        B[Orientado al Diseño]
        D[Modelado]
    end

    subgraph T3[Motor]
        C[Agregación]
        E[Aplicación]
        F[Versionado]
    end

    A <--> B
    A <--> D

    B <--> D

    D <--> C
    D <--> E
    D <--> F

4.2.1. Modelado#

Tu modelo de datos es crítico: determina qué puedes representar y con qué facilidad puedes trabajar con ello. Como señaló George Box: “Todos los modelos son incorrectos, pero algunos son útiles”. No hay un modelo perfecto que funcione para todos. En mi experiencia, el modelado de datos es más arte que ciencia. Pero ciertos patrones aparecen de forma consistente en los proyectos exitosos.

4.2.1.1. Principios Fundamentales#

Cómo organizas tus datos importa. Determina qué puedes expresar y con qué eficiencia los sistemas pueden validarlo y usarlo. Los diferentes formatos tienen diferentes compromisos. YAML es legible pero valida poco. JavaScript Object Notation (JSON) funciona en todas partes pero es verboso. Yet Another Next Generation (YANG) añade validación pero tiene una curva de aprendizaje pronunciada. Elige según lo que realmente necesites.

Tus datos existen a diferentes niveles. La misma pieza de red puede describirse de múltiples formas para diferentes propósitos:

• Nivel de servicio: Amigable para el negocio (“configurar una L3VPN MPLS para la sucursal X”)
• Nivel técnico: Especificaciones técnicas (“BGP AS 65001, route targets 65001:100, políticas…”)
• Nivel de dispositivo: Configuraciones reales (“interface xe-0/0/0; unit 100;…”)

Los buenos modelos conectan estas capas. Puedes empezar a nivel de negocio y luego generar configuraciones de dispositivos automáticamente. Pero no siempre necesitas las tres capas: depende de lo que estés construyendo.

4.2.1.2. Persistencia de Datos y Escala#

Elegir cómo almacenar los datos del modelo tiene implicaciones profundas para la consistencia, el rendimiento y la evolución. Estas implicaciones se vuelven críticas a medida que tu red crece de cientos a cientos de miles de objetos gestionados.

• Bases de datos relacionales (p. ej., MySQL, PostgreSQL): Esta es la apuesta segura para la mayoría de los equipos. Imponen consistencia de esquema, proporcionan transacciones ACID y todos los ingenieros de tu equipo ya conocen SQL. Destacan en representar jerarquías normalizadas (VLANs que contienen interfaces) y en prevenir anomalías de datos. La desventaja: los cambios de esquema son dolorosos a escala, y el rendimiento se degrada con uniones profundas en millones de filas. Pero eso es un buen problema: significa que realmente has desplegado algo.

• Bases de datos de documentos (p. ej., MongoDB, CouchDB): Ideales si necesitas flexibilidad de esquema y escalabilidad horizontal. Los documentos modelan naturalmente estructuras anidadas (un dispositivo con todas sus configuraciones y metadatos como un único bloque). Pero el inconveniente es que ahora eres responsable de la consistencia entre documentos y las consultas complejas se encarecen rápidamente. A menos que tengas una razón específica para usar documentos, quédate con el modelo relacional.

• Bases de datos de grafos (p. ej., Neo4j): Son genuinamente mejores cuando las relaciones importan más que los objetos: “¿A qué VLANs se conecta esta interfaz? ¿Qué dispositivos enrutan entre estas dos ubicaciones?” Atraviesan relaciones de profundidad arbitraria eficientemente. Pero a menos que estés haciendo consultas complejas de topología constantemente, estás eligiendo la opción exótica. Las bases de datos de grafos resuelven problemas reales, pero asegúrate de tener esos problemas antes de elegirlas.

flowchart TD
    Q1{¿Requisito principal?}
    Q1 -->|Recorrer relaciones complejas en profundidad| Q2{¿Consultas de topología constantes?}
    Q1 -->|Esquema evoluciona frecuentemente| DB_D[Base de datos documental]
    Q1 -->|Consultas estructuradas, integridad referencial| DB_R[Base de datos relacional]
    Q2 -->|Sí| DB_G[Base de datos de grafos]
    Q2 -->|Ocasionalmente| DB_R

    style DB_R fill:#ccffcc,stroke:#28a745
    style DB_G fill:#cce5ff,stroke:#4a90e2
    style DB_D fill:#ffffcc,stroke:#ffc107

Más sobre persistencia de datos, desde una perspectiva diferente, en el capítulo de Observabilidad.

La selección de base de datos es uno de los diferenciadores clave entre productos en este espacio. Por ejemplo, NetBox y Nautobot usan bases de datos relacionales, mientras que Infrahub usa una base de datos de grafos, como puedes ver en la sección 4.2.9.

La persistencia también puede implementarse mediante almacenamiento basado en archivos con modelos de datos como YAML o JavaScript Object Notation (JSON) (o CSV), habitualmente rastreados en sistemas Git para el control de versiones.

La mayoría de los sistemas de Fuente de Verdad en producción usan persistencia políglota: una base de datos relacional para la intención autorizada y las relaciones, almacenamiento de documentos o Git para flexibilidad y caché, y capacidades de grafo para el análisis de topología.

¿Qué tan granular debe ser tu modelo? Si modelas cada interfaz en cada dispositivo como un objeto separado, acabas con más de 50.000 objetos para una red mediana. Las consultas se vuelven lentas. Las actualizaciones se convierten en un dolor.

El enfoque práctico: usa plantillas para los patrones comunes. Di “las interfaces 1-40 usan esta plantilla estándar” y solo rastrea las excepciones. Son 2 objetos en lugar de 40, las consultas se mantienen rápidas y el renderizado sigue funcionando.

En el Capítulo 11, cubriremos más información sobre cómo decisiones como esta impactan el rendimiento.

4.2.1.3. Dominios de Datos de Red#

Las implementaciones completas de Fuente de Verdad típicamente modelan estos dominios interconectados:

• Inventario y Activos: Dispositivos físicos y lógicos, especificaciones de hardware, números de serie, fecha de adquisición, términos del contrato, etapa del ciclo de vida
• Infraestructura de Centro de Datos: Ubicaciones (geográficas y jerárquicas), edificios, plantas, salas, racks, distribución de energía, rutas de cables
• Gestión de Direcciones IP (IPAM): Grupos de direcciones, subredes, asignaciones, resolución DNS, ámbitos DHCP, seguimiento de utilización
• Virtualización y Nube: VPCs, subredes, grupos de seguridad, instancias de cómputo, almacenamiento, relaciones de orquestación de contenedores
• Conectividad: Circuitos físicos (MPLS, Ethernet), túneles virtuales, relaciones de peering, asignaciones de ancho de banda, políticas QoS
• Enrutamiento: Comunidades BGP, sistemas autónomos, políticas de enrutamiento, listas de prefijos, route targets para servicios L3VPN
• Servicios: Definiciones de servicios lógicos (L3VPN, L2VPN, tránsito de firewall), mapeos servicio-dispositivo, SLAs
• Seguridad y Cumplimiento: Listas de control de acceso, reglas de firewall, zonas de seguridad, etiquetas de cumplimiento, requisitos de auditoría
• Gestión: Detalles SNMP, suscripciones gNMI, fuentes NTP, destinos syslog, integración TACACS+/RADIUS

Estos dominios son interdependientes: el Enrutamiento hace referencia a la Conectividad, los Servicios abarcan Inventario e IPAM, las políticas de Seguridad se aplican tanto a Dispositivos como a Servicios. Un SoT bien diseñado modela estas relaciones explícitamente en lugar de tratar cada dominio como una tabla aislada.

graph TD
    INV[Inventario y Activos]
    DC[Infraestructura del Centro de Datos]
    IPAM[Gestión de Direcciones IP]
    VIRT[Virtualización y Nube]
    CONN[Conectividad]
    ROUTE[Enrutamiento]
    SVC[Servicios]
    SEC[Seguridad y Cumplimiento]
    MGMT[Gestión]

    DC --> INV
    INV --> IPAM
    INV --> MGMT
    CONN --> INV
    VIRT --> IPAM
    ROUTE --> CONN
    SVC --> INV
    SVC --> ROUTE
    SVC --> IPAM
    SEC --> INV
    SEC --> SVC

    classDef foundation fill:#ddeeff,stroke:#4a90e2,stroke-width:2px
    classDef overlay fill:#e8f5e9,stroke:#28a745
    classDef policy fill:#fff3cd,stroke:#ffc107
    class INV,IPAM,CONN foundation
    class ROUTE,VIRT,DC,MGMT overlay
    class SVC,SEC policy

Más allá de los dominios específicos de red, se necesitan muchos otros tipos de datos. Por ejemplo, un backend de secretos para almacenar credenciales.

Quiero compartir una pregunta habitual en muchos equipos que debaten usar una fuente de datos específica para redes, como NetBox, frente a una de propósito general como ServiceNow. En mi experiencia, aunque es posible lograr resultados similares, el hecho de que ServiceNow sea un sistema corporativo lo hace más difícil (y lento) de evolucionar, lo que ralentiza a los equipos de red a la hora de aprovechar su potencial para una representación completa de la red.

Clasificación de Datos y Atributos Comunes

En los dominios de red, ciertos patrones de clasificación aparecen de forma consistente. Los modelos bien diseñados incluyen estos atributos fundamentales:

• Rol: ¿Qué propósito cumple este objeto? (core, distribución, acceso; primario, secundario)
• Estado: ¿Está activo, planificado, en proceso de retiro o retirado?
• Tipo: ¿Qué tipo de objeto es? (VLAN, dispositivo, circuito, servicio)
• Propiedad: ¿Qué equipo o unidad de negocio lo gestiona?
• Ubicación: ¿Dónde está situado este recurso geográfica u organizacionalmente?

4.2.1.4. Patrones de Diseño del Modelo: Extensibilidad, Polimorfismo y Migraciones#

Algunas soluciones vienen con un modelo integrado basado en lo que sus creadores piensan que deben ser las redes. Otras soluciones te permiten construirlo desde cero. Normalmente, el mejor enfoque es híbrido: usa los modelos integrados para tus casos comunes (el 80% que todo el mundo hace), pero asegúrate de poder extenderlos para tus necesidades específicas.

¿Por dónde deberías empezar realmente? Esto es lo que le digo a todo el mundo: empieza con herramientas con modelos opinados como NetBox, Nautobot o Infrahub. Punto. Los equipos que dicen “construiremos nuestro propio modelo perfecto” siguen modelando dos años después, mientras los equipos con estas herramientas entregaron modelos válidos muchos meses antes.

La única decisión que importa: ¿puedes extender sin reescribir? Si añadir un campo personalizado para rastrear “centro de costes” requiere reconstruir todo tu esquema, huye. Si puedes añadirlo como atributo personalizado en 20 minutos, has encontrado la herramienta adecuada.

Polimorfismo: un modelo, múltiples variantes

No todas las interfaces son iguales. Un puerto óptico físico y una interfaz de túnel comparten algunas propiedades, pero son objetos diferentes. Define un modelo base compartido que cubra lo que tienen en común y luego crea variantes especializadas para los detalles que difieren.

# All interfaces share these basics
interfaces:
  - name: "eth0"
    type: "physical"
    status: "up"
    mtu: 1500
    ipv4_address: "192.0.2.1/24"

# But a physical optical port has extra stuff
  - name: "eth0"
    type: "physical_optical"
    optics_module: "100GBASE-LR4"
    tx_power_dbm: -2.5

# And a tunnel looks totally different
  - name: "tun-vpn-dallas"
    type: "tunnel_gre"
    tunnel_source: "203.0.113.1"
    tunnel_destination: "198.51.100.5"

Los modelos cambian: planifícalo

Las redes viven décadas. Tu modelo no permanecerá estático. Estrategias para gestionar cambios sin romper las cosas: marca las cosas como obsoletas antes de eliminarlas, admite alias de campos durante la transición, crea ayudantes de migración y prueba con todo lo que depende de tus datos.

4.2.1.5. Plantillas de Configuración#

Las plantillas convierten la intención abstracta (“quiero una VLAN”) en comandos Command Line Interface (CLI) reales. La regla clave: las plantillas contienen lógica, no datos. Jinja2 es popular porque es legible para humanos, está integrado con Python y Ansible, y es práctico para redes reales.

interfaces:
  - name: Ethernet1
    description: Uplink to core
    enabled: true

{% for iface in interfaces %}
interface {{ iface.name }}
  description {{ iface.description }}
  {% if iface.enabled %}no shutdown{% else %}shutdown{% endif %}
{% endfor %}

Una alternativa interesante a Jinja es el lenguaje de configuración declarativo CUE, que unifica datos sin formato, validación de esquema y generación dinámica de datos en un único lenguaje con invariantes impuestos.

4.2.2. Orientado al Diseño#

Cuando tienes 50 dispositivos y 30 VLANs, puedes gestionarlos individualmente. Cuando tienes 5.000 dispositivos y cientos de servicios, la gestión manual es imposible. El bloque orientado al diseño resuelve esto: los operadores describen lo que quieren a alto nivel (“añadir una sucursal”) y el sistema lo expande en especificaciones técnicas completas.

4.2.2.1. De la Intención de Negocio a los Datos Técnicos#

Escenario de ejemplo - “Añadir oficina sucursal en Dallas”:

flowchart LR
    A[Intención de Negocio]
    B[Aplicar Plantilla]
    C[Asignar Recursos]
    D[Resolver Lógica]
    E[Renderizar Detalles]
    F[Objetos para el Ejecutor]

    A --> B --> C --> D --> E --> F

    style A fill:#fff3cd,stroke:#ffc107
    style B fill:#ffe6cc,stroke:#fd7e14
    style C fill:#d4edda,stroke:#28a745
    style D fill:#cce5ff,stroke:#4a90e2
    style E fill:#e2d9f3,stroke:#6f42c1
    style F fill:#d1ecf1,stroke:#17a2b8

4.2.2.2. Patrones de Diseño y Bloques Reutilizables#

Los sistemas de diseño efectivos dependen de bibliotecas de patrones que codifican decisiones arquitectónicas probadas. Cada patrón (Oficina Sucursal Pequeña, Hub Regional Mediano, Borde de Centro de Datos) encapsula el conjunto completo de decisiones técnicas para ese tipo de sitio. Desviarse requiere aprobación explícita, pero desplegarlos debería verse como una operación normal.

4.2.2.3. Hacer los Diseños Reproducibles#

Cada vez que hagas una solicitud de diseño, registra qué diseño obtuvo qué recursos. Si llega la misma solicitud de nuevo, obtienes la misma VLAN. Esto requiere rastrear permanentemente las asignaciones de solicitud a recurso y asignar siempre en el mismo orden. Esta es la razón por la que muchos sistemas de diseño usan almacenamiento con direccionamiento por contenido (hash del diseño) para garantizar la consistencia.

4.2.2.4. Distinción entre Renderizar y Construir#

Los sistemas de diseño separan dos fases: Renderizar (sin efectos secundarios, para revisión y validación) y Construir (cambios reales con operación atómica, monitorizable y reversible). Admitir renderizar sin construir permite validación segura antes del compromiso y análisis hipotético sin riesgo.

4.2.2.5. Versionado y Evolución del Diseño#

Almacena las definiciones de diseño en control de versiones (diseño-como-código) y referencia versiones específicas desde cada sitio. Esto permite migraciones graduales (actualizar sitio por sitio) y revertir si una nueva versión tiene problemas. Para sitios con requisitos especiales, aplica el diseño estándar como base y luego añade anulaciones específicas del sitio rastreadas por separado.

4.2.3. Consumo#

Los datos encerrados en una base de datos son inútiles. La capa de consumo es cómo las personas y los sistemas acceden realmente a los datos. Hazlo fácil y obtienes adhesión. Hazlo difícil y la gente lo evitará.

4.2.3.1. Diseño y Seguridad de la API#

Una regla crítica: haz la autenticación y autorización en la capa de la API, no en las capas inferiores.

Más sobre implicaciones de seguridad en el Capítulo 12.

4.2.3.2. Operaciones de API: Versionado, Rendimiento y Caché#

Anuncia los cambios de ruptura con 6-12 meses de antelación. Recomiendo usar versionado por URL (/api/v1/devices y /api/v2/devices): cuando algo se rompe a las 3 de la mañana y estás buscando en los registros, quieres ver /v1/ vs /v2/ inmediatamente.

Las operaciones masivas permiten actualizar miles de objetos en una única llamada a la API, esencial para la escala. Otras mejoras incluyen paginación y filtrado, estrategias de caché (Redis en servidor, ETags HTTP en cliente) y limitación de tasa para proteger los backends.

4.2.3.3. Modelado de Datos Contextual#

Diferentes personas necesitan cosas diferentes. En lugar de devolver todos los campos a todos, da a cada consumidor solo lo que necesita:

GET /api/devices/router-core-01?view=network-engineer
→ {interfaces: [...], bgp_peers: [...], vlans: [...]}

GET /api/devices/router-core-01?view=finance
→ {cost_center: "...", warranty_expiry: "...", purchase_cost: ...}

La interfaz de usuario del bloque de consumo pertenece a la capa de Presentación. Cubriremos más sobre esto en el Capítulo 8.

4.2.3.4. Interfaces Asistidas por IA#

Tres patrones son cada vez más comunes: sugerencias contextuales (reduce errores de entrada), advertencias de anomalías al escribir (señala operaciones inusuales antes de ejecutarlas) y consultas en lenguaje natural (los operadores consultan el SoT con lenguaje ordinario, el sistema traduce a consultas estructuradas). Todos dependen del acceso a datos históricos de operaciones y un esquema bien modelado.

4.2.4. Aplicación#

Los datos incorrectos destruyen la automatización. La Aplicación es tu guardián: detiene los datos obviamente incorrectos en la entrada y explica claramente por qué.

4.2.4.1. Aplicación de Esquema y Restricciones#

4.2.4.2. Aplicación Dura vs. Blanda#

Rechaza los datos incorrectos. Parada total. He visto demasiados sistemas de “validación blanda” convertirse en vertederos porque “solo por esta vez” se convierte en el procedimiento operativo estándar. Las excepciones son: directrices de política (advertir pero permitir con anulación), comprobaciones costosas entre objetos (aceptar y validar de forma asíncrona) y descubrimiento de redes brownfield (marcar pero no bloquear la importación).

4.2.4.3. Compromisos de Coste de Validación y Rendimiento#

La validación no es gratuita. Los sistemas prácticos eligen un objetivo de rendimiento y validan solo hasta ese nivel para las rutas de escritura síncronas: ruta rápida (<10ms) para tipo, regex y comprobaciones de índice local; ruta estándar (<100ms) para unicidad e integridad referencial; ruta lenta (<5s) para motor de reglas; ruta asíncrona (horas después) para comprobaciones de consistencia en segundo plano.

4.2.4.4. Calidad de Datos Mejorada con IA#

El aprendizaje automático mejora la calidad de los datos: detección de anomalías (compara patrones históricos con nuevas solicitudes), sugerencias de autocorrección (sugiere la solución válida más probable) y embeddings vectoriales para consistencia (detecta desviaciones significativas de las configuraciones de pares). Siempre muestra por qué la IA marcó un problema para construir confianza del operador en las recomendaciones.

4.2.5. Versionado#

La intención de tu red cambia constantemente. El Versionado te permite entender qué era verdad en qué momento, cómo llegó a serlo y cómo volver a algo seguro si es necesario.

4.2.5.1. Control de Versiones y Registros de Auditoría Inmutables#

Todos los cambios deben registrarse de forma inmutable, creando un historial completo:

Change Event:
  timestamp: 2025-02-07T14:32:15Z
  user: engineer@company.com
  action: UPDATE
  resource_type: vlan
  resource_id: vlan-100
  changes:
    description: "Customer VLAN" → "Production Customer VLAN"
  reason: "Adding new office location"

La inmutabilidad es la clave: nadie, ni siquiera los administradores, puede editar los registros históricos. Esto previene encubrimientos y garantiza que los registros de auditoría permanezcan de confianza.

4.2.5.2. Patrones de Control de Versiones: Ramificación, Fusión y Reversión#

Los sistemas modernos de Fuente de Verdad toman prestados los patrones del control de versiones de software. Cualquier organización con más de un ingeniero o agente de IA trabajando en paralelo necesita mecanismos de ramificación para trabajar sin bloquear a otros, con fusiones que resuelven cualquier inconsistencia introducida.

Implementar este mecanismo en bases de datos tradicionales es un problema importante. NetBox usa copias de base de datos para la ramificación, mientras que Nautobot aprovecha Dolt (una base de datos SQL con capacidades similares a Git). Infrahub, diseñado desde cero con ramificación similar a Git en mente, usa una base de datos de grafos con capacidades de ramificación nativas.

La Rollback de datos puede implementarse mediante Snapshots (copias periódicas completas, recuperación rápida, alto overhead de almacenamiento), Event Sourcing (registrar todos los cambios como eventos, menor almacenamiento, recuperación más lenta) o un enfoque Híbrido (snapshots cada N horas más registro de eventos entre medias).

4.2.5.3. Transacciones Atómicas y Garantías de Consistencia#

Las garantías transaccionales (Atomicidad, Consistencia, Aislamiento, Durabilidad) aseguran la consistencia de los datos cuando múltiples cambios relacionados deben tener éxito o fallar juntos.

En el Capítulo 11, cubriremos más sobre cómo estos requisitos impactan los sistemas fiables.

4.2.5.4. Flujos de Trabajo de Aprobación de Cambios#

No todos los cambios requieren aprobación humana, y aquí es donde la mayoría de las organizaciones se equivocan. Los comités de control de cambios son donde la automatización va a morir. No estoy diciendo que se salten las aprobaciones, estoy diciendo que las automaticen.

La regla es: los cambios que encajan dentro de guardarraíles claros proceden automáticamente; solo la lógica de los guardarraíles en sí requiere revisión y aprobación humana. De lo contrario, tu “automatización” es simplemente una forma más elegante de esperar reuniones.

4.2.6. Agregación#

Tus datos de red no viven en un vacío. Los sistemas de RR.HH. rastrean quién trabaja dónde. La gestión de activos conoce los detalles y fechas de garantía de los dispositivos. Los sistemas IPAM poseen las asignaciones de direcciones IP.

No construyas otro silo de datos. La Agregación no es opcional: incorpora datos de los sistemas existentes, mantenlos sincronizados en ambas direcciones y presenta una vista unificada. La fuente de verdad debería ser una capa de federación, no una base de datos de reemplazo.

4.2.6.1. No Empiezas desde Cero#

Casi con certeza tienes datos dispersos entre múltiples sistemas. Cada sistema es autorizado para su dominio. La fuente de verdad no reemplaza estos sistemas; reúne sus datos en una interfaz consistente para que los clientes no tengan que consultar cinco sistemas diferentes.

4.2.6.2. Resolución de Conflictos en Sistemas Federados#

Cuando los datos vienen de múltiples fuentes, surgen conflictos. La resolución requiere designación de autoridad a través de la gobernanza. Las estrategias incluyen: Autoridad de Fuente (decisión de gobernanza que designa un sistema como autorizado), basada en Timestamp, Resolución Lógica (evalúa el contexto) y Escalado Manual.

4.2.6.3. Arquitectura de Agregación#

4.2.6.4. Mecanismos de Sincronización#

No existe un sistema de sincronización en tiempo real. Los datos llegarán a ser eventualmente consistentes, pero esto puede llevar algún tiempo que debe evaluarse para cada caso de uso.

4.2.6.5. Marcos de Gobernanza y Autoridad de Datos#

La federación efectiva requiere una gobernanza clara con definiciones explícitas por dominio de datos. Para cada elemento de datos, los metadatos de autoridad deben rastrear el sistema de origen, la última hora de sincronización, el método de actualización y el nivel de autoridad.

Prepárate para los fallos. Los sistemas externos inevitablemente fallarán. Las estrategias incluyen: bloquear operaciones, usar datos en caché marcados como obsoletos, o degradar con elegancia (continuar sin la funcionalidad afectada y encolar para cuando se recupere el sistema).

4.2.7. Incorporación de Redes Brownfield#

Cuando despliegas una fuente de verdad en una red existente, te enfrentas a un problema complicado: ¿cómo la poblas con el estado actual sin solo incorporar toda tu deuda técnica heredada como verdad permanente?

El enfoque incorrecto: Sondear tus dispositivos y asumir “lo que está en ejecución = lo que debería estar”. Cargarás todos los parches, hacks y deuda técnica directamente en la fuente de verdad.

El enfoque correcto: Usa el estado actual de la red como punto de partida, no como la verdad:

1. Bootstrap: Toma un snapshot de tu red actual y cárgalo como datos iniciales.
2. Rediseño: A lo largo de semanas y meses, haz que las personas revisen esos datos y decidan cuál debería ser realmente el estado previsto.
3. Cambiar la dirección: Una vez que tienes el diseño que quieres, deja de sincronizar desde la red. La fuente de verdad se convierte en el jefe.
4. Detectar deriva: La Observabilidad (Capítulo 6) vigila los dispositivos que se desvían de lo que dice la fuente de verdad.

Hay herramientas como Slurpit.io o extensiones para NetBox o Nautobot enfocadas en este problema.

4.2.8. Ciclo de Vida de los Datos y Reconciliación#

Los datos se vuelven obsoletos. Un switch se retira sin eliminarse del SoT. Una dirección IP se reasigna manualmente durante un incidente. Sin un proceso de reconciliación continuo, el SoT gradualmente pierde credibilidad: los equipos dejan de confiar en él, empiezan a mantener sus propias hojas de cálculo y la automatización construida sobre él empieza a producir resultados incorrectos silenciosamente.

El patrón de reconciliación significa comparar periódicamente el estado real de la red con el SoT y clasificar cada discrepancia:

• Deriva de configuración: el dispositivo difiere de su intención en el SoT. El SoT es correcto; la red se ha desviado. Activa el bloque de Ejecución para remediarlo.
• Cambio no registrado: se realizó un cambio deliberado en la red pero no se registró en el SoT. La red es correcta; el SoT está obsoleto. Alerta al operador.
• Registro huérfano: el SoT tiene un objeto para algo que ya no existe en la red. Poner en cola para revisión de limpieza.

El SoT como dependencia en vivo

Hay una diferencia estructural entre un SoT usado como referencia (leído una vez al inicio del flujo de trabajo) y uno usado como dependencia en vivo (leído en cada paso). Para flujos de trabajo de larga duración, la ventana de obsolescencia es significativa. El Orquestador debería validar que la lectura del SoT tuvo éxito y devolvió un registro actual antes de iniciar un paso de expansión. Si el SoT no está disponible, el flujo de trabajo debería fallar limpiamente con un error claro, no proceder con un snapshot de edad desconocida.

4.2.9. Panorama de Soluciones#

Hay muchos productos de fuente de verdad disponibles. Esta es una instantánea de principios de 2026: el panorama cambia constantemente, así que consulta siempre las capacidades actuales antes de elegir.

4.2.9.1. Soluciones de Código Abierto#

4.2.9.2. Soluciones Comerciales#

Todas las soluciones de código abierto listadas anteriormente también tienen una oferta comercial.

4.2.9.3. Plataformas Especializadas#

4.2.9.4. Consideraciones de Selección#

Al evaluar soluciones de Fuente de Verdad, considera: requisitos de escala (número de dispositivos, tasa de cambio, volumen de consultas), necesidades del modelo de datos (relacional vs. grafo vs. documento flexible), ecosistema de integración, experiencia del equipo, modelo operativo (autoalojado vs. SaaS, procesos de aprobación de cambios) y trayectoria de evolución (ruta de migración brownfield, extensibilidad del esquema, estabilidad de la API).

4.3. Ejemplo de Implementación#

4.3.1. Caso de Uso: Construyendo el SoT para la Red del Campus#

Volvemos a la red del campus introducida en el Capítulo 3. Con aproximadamente 800 switches de acceso y distribución de Cisco, Arista y HPE distribuidos en múltiples edificios, el equipo de operaciones gestiona un flujo constante de solicitudes de servicio: nuevas VLANs, asignaciones de subredes IP, actualizaciones de políticas de enrutamiento y cambios de control de acceso. Antes de que cualquiera de eso pueda automatizarse de forma fiable, los datos tienen que estar en un lugar consistente y autorizado.

Hoy el campus opera con tres sistemas separados:

• Infoblox: IPAM autorizado que gestiona la asignación de direcciones IP, asignaciones de prefijos y DNS
• ServiceNow: Inventario de activos y CMDB que rastrea ubicaciones de switches, modelos de hardware, asignaciones de edificios
• Switches del campus: La configuración en ejecución real, distribuida entre 800 dispositivos sin una vista consolidada única

Desafío: Cuando el equipo de aplicaciones envía una solicitud para un nuevo segmento de servicio VLAN, el ingeniero de red tiene que cruzar referencias manualmente entre Infoblox, ServiceNow y sesiones SSH de dispositivos. La Configuration Drift se acumula porque no hay un único acuerdo sobre cuál debería ser el estado previsto de cada switch.

Solución: Desplegar Nautobot como una Fuente de Verdad de Red federada que se integra con Infoblox y ServiceNow, extrae el estado actual de los switches del campus y añade el modelo de datos específico de red que ninguno de los dos puede proporcionar: definiciones de VLAN, plantillas de configuración por proveedor, patrones de diseño para las capas de acceso y distribución.

Este ejemplo es ilustrativo, no prescriptivo. Hay muchos productos y arquitecturas de SoT válidos que podrían resolver este escenario. El punto es demostrar cómo los seis bloques de construcción trabajan juntos en un escenario real. Tu organización probablemente tendrá un SoT diferente basado en las herramientas existentes, la experiencia del equipo y las restricciones.

4.3.2. Arquitectura de la Solución#

graph TB
    IPAM["Infoblox\nAuthoritative IPAM\nIP ranges, DNS"]
    CMDB["ServiceNow\nAuthoritative CMDB\nAssets, locations, metadata"]
    DEVICES["Campus Switches\nCisco, Arista, HPE\n~800 devices"]
    SLURPIT["Slurpit\nBrownfield Discovery\nConfig extraction"]

    subgraph NAUTO ["Nautobot (Aggregation Hub)"]
        direction TB
        AGG["Aggregation Layer\nAuthority rules\nConflict resolution"]
        SOT["Consolidated SoT\nDevices, IPs, sites\nrelationships"]
        API["Consumption APIs\nREST, GraphQL\nWebhooks"]
    end

    EXEC["Execution System\nConfig generation\nDevice deployment"]
    OBS["Observability\nState validation\nDrift detection"]
    UI["Presentation\nWeb UI, CLI\nDashboards"]

    IPAM -->|Webhooks/Polling\nIP data| AGG
    CMDB -->|Webhooks/Polling\nAsset data| AGG
    DEVICES -->|SSH/NETCONF\nDevice state| SLURPIT
    SLURPIT -->|Transformed data\nInitial bootstrap| AGG
    AGG --> SOT
    SOT --> API
    API -->|Intent queries| EXEC
    API -->|Config templates| EXEC
    API -->|Data access| UI
    OBS -->|State Drift| API
    API -->|Inventory| OBS
    EXEC -.->|Deploy configs| DEVICES
    OBS -.->|Monitor state| DEVICES

La clave: Nautobot no está reemplazando Infoblox ni ServiceNow. Está agregando sus datos, resolviendo conflictos y sirviendo como la única API que consumen los sistemas aguas abajo. Esta separación de responsabilidades permite que cada sistema sea el mejor de su clase.

4.3.3. Flujo de Implementación#

Carga de datos inicial

1. Importación de Infoblox: Nautobot se conecta a la API de Infoblox y extrae todos los rangos IP, reservas y registros DNS.
2. Importación de ServiceNow: Nautobot se conecta al CMDB de ServiceNow y extrae todos los activos TI, ubicaciones y relaciones.
3. Descubrimiento de red brownfield con Slurpit: Slurpit.io se conecta a los dispositivos de red existentes para extraer el estado de configuración actual y los transforma en modelos de datos compatibles con Nautobot.
4. Detección y resolución de divergencias: El proceso de auditoría correlaciona datos de las tres fuentes. Se marcan conflictos para revisión humana, con reglas de gobernanza que guían la resolución (p. ej., “confiar en el dispositivo para puertos de acceso, confiar en IPAM para IPs de infraestructura”).

Operaciones en vivo

1. Nueva solicitud de servicio VLAN: El equipo de aplicaciones envía una solicitud en ServiceNow. Nautobot captura el webhook, crea los objetos VLAN y prefijo, consulta Infoblox para el próximo /24 disponible en el rango de building-b y lo asigna automáticamente. El bloque de Ejecución puede ahora consultar Nautobot para todos los datos que necesita para desplegar el servicio en todos los switches de destino.
2. Nuevo switch del campus incorporado: El operador crea la entrada de activo en ServiceNow. Nautobot captura el webhook, crea el objeto de dispositivo con metadatos de ubicación, proveedor y rol, y asigna la plantilla de diseño apropiada.
3. Ventana de mantenimiento de Infoblox: El IPAM se queda sin conexión durante 2 horas. Nautobot muestra datos en caché marcados como “datos de IP válidos hasta las 14:30 UTC; actualización pendiente”. Cuando Infoblox se recupera, las asignaciones pendientes se procesan atómicamente.

4.3.4. Compromisos del Enfoque#

Ventajas

Limitaciones

4.4. Resumen#

La regla del firewall huérfana del inicio no fue un error de configuración. Nadie dejó de hacer su trabajo. La regla se quedó porque no había ningún sistema que conectara la VLAN con el servicio y la política del firewall. Cuando se eliminó la VLAN, esa conexión no existía, por lo que la regla no tenía nada que activara su limpieza. La fuente de verdad es el sistema que hace esas conexiones explícitas.

Seis funcionalidades construyen ese sistema. El Modelado define cómo se supone que debe verse la red y a qué nivel de abstracción. El Orientado al Diseño traduce una solicitud de negocio (“añadir sucursal Dallas”) en los más de 50 objetos técnicos que el Ejecutor necesita antes de tocar un dispositivo. El Consumo pone esa intención a disposición de forma consistente para humanos, flujos de trabajo de automatización y otros sistemas. La Aplicación garantiza que los datos que entran en el SoT son válidos antes de que puedan producir un estado de red incorrecto aguas abajo. El Versionado registra cada cambio con autor, razón y timestamp, haciendo el SoT auditable y recuperable. La Agregación conecta el SoT con los sistemas autorizados que ya poseen partes de los datos: IPAM para direcciones, CMDB para activos, proveedores de circuitos para conectividad.

El ejemplo de implementación del campus mostró los seis trabajando juntos: Nautobot como hub de federación, Infoblox y ServiceNow como fuentes autorizadas para sus respectivos dominios, plantillas de diseño que traducen una solicitud de servicio VLAN en todo lo necesario para el despliegue automatizado. El resultado no es solo una base de datos del estado de la red. Es la referencia única que consulta cada otro bloque de construcción para saber cómo se supone que debe ser la red.

El Capítulo 5 toma esa intención y la convierte en acción: el bloque de Ejecución lee del SoT y aplica cambios a la red, con las garantías de consistencia y comportamiento de reversión que hace posible la funcionalidad de Versionado del SoT.

💬 Found something to improve? Send feedback for this chapter