OSIRIS JSON para Cisco

Cisco no es un unico objetivo para producers. Son varias superficies de infraestructura distintas que necesitan converger en un unico modelo portable.

Precisamente por eso Cisco es una direccion importante para OSIRIS JSON. Un producer para Cisco APIC, Cisco NX-OS y Cisco IOS no deberia aplanar esos mundos en la misma exportacion en bruto. Deberia traducir cada uno de ellos a un lenguaje de topologia compartido, preservando al mismo tiempo los detalles especificos del vendor que siguen importando aguas abajo.

Tres superficies de Cisco, un objetivo de intercambio

El reto del producer es distinto en cada caso.

Cisco APIC expone una vista de fabric basada en controladores y politicas
Cisco NX-OS expone inventario y relaciones de switching de datacenter centrados en el dispositivo
Cisco IOS expone estado clasico de routing, acceso y redes de campus

No son modelos fuente intercambiables, pero aun asi pueden alimentar la misma estructura de documentos OSIRIS. Ese es el objetivo del estandar: normalizar infraestructura heterogenea sin fingir que las fuentes eran identicas.

APIC no deberia forzarse a una exportacion generica de switches

Cisco APIC es el ejemplo mas claro de por que OSIRIS necesita tanto campos core como namespaces de vendor.

Un producer respaldado por APIC no se limita a descubrir dispositivos aislados. Trabaja con constructos a nivel de fabric, limites de politicas y relaciones mediadas por el controlador. En terminos de OSIRIS, eso significa que un producer aun puede emitir recursos, grupos y conexiones portables para el grafo que necesitan los consumers genericos, preservando al mismo tiempo la semantica especifica de ACI dentro del espacio de extensiones de Cisco.

La especificacion ya deja sitio para esa direccion mediante extensiones de Cisco con namespace y tipos especificos de vendor como osiris.cisco.aci.fabric. Ese es el lugar correcto para el significado nativo de ACI que no deberia forzarse dentro del schema core.

NX-OS encaja muy bien con la topologia core

Cisco NX-OS es un objetivo muy natural para producers de OSIRIS porque la infraestructura subyacente ya se mapea de forma limpia al modelo estandar.

Los fabrics Nexus suelen girar en torno a recursos de switch, interfaces, uplinks, peerings, VLAN, contexto de routing y relaciones fisicas o logicas explicitas. Esas son exactamente las clases de estructuras que OSIRIS esta pensado para transportar. Un buen producer de NX-OS deberia poder emitir:

recursos network.switch para dispositivos Nexus
ID deterministas y atribucion estable del provider usando cisco
conexiones explicitas para enlaces, peerings y rutas de attachment
grupos para limites de fabric, sitio, rack, pod o entorno
propiedades portables para modelo, IP de gestion, version y contexto a nivel de interfaz

Si un producer de Cisco no puede expresar con claridad un switch fabric en OSIRIS, el problema no es el dominio. Es el producer.

IOS importa porque el borde de red sigue importando

Cisco IOS puede parecer menos de moda que los fabrics dirigidos por controladores, pero sigue siendo esencial para la historia de producers en OSIRIS.

Routers, dispositivos de sucursal, equipos de la capa de acceso y bordes de red heredados pero criticos son exactamente la clase de sistemas que tienden a vivir fuera de pipelines de topologia pulidos. OSIRIS tambien necesita manejar esos entornos.

El estandar ya tiene mapeos directos para infraestructura comun del estilo IOS como network.router, network.switch, network.vlan y las relaciones que los rodean. Eso convierte a IOS en un ejemplo solido del principio de producer que mas importa en la practica: normalizar primero la forma portable y luego preservar el contexto nativo del vendor cuando haga falta.

Detalle especifico de Cisco sin perder interoperabilidad

En APIC, NX-OS e IOS, la regla del producer sigue siendo la misma: mantener portable la topologia core y mantener en namespaces la semantica de Cisco.

Eso significa:

usar tipos estandar de recursos y conexiones de OSIRIS cuando ya expresen el concepto
mantener estable la atribucion del provider con nombres canonicos de Cisco
almacenar en properties los atributos intrinsecos y ampliamente utiles
almacenar en extensions las estructuras nativas de Cisco, usando namespaces como osiris.cisco
preservar la semantica mas profunda especifica de ACI bajo patrones dedicados de extension de Cisco o de tipo vendor en lugar de filtrarla al modelo core

Aqui es donde OSIRIS es mas fuerte que las exportaciones ad hoc. Un consumer que no sepa nada sobre Cisco aun deberia ser capaz de construir el grafo. Un consumer consciente de Cisco puede despues profundizar sin romper la portabilidad para todos los demas.

El contrato del producer sigue aplicando

Un producer de Cisco sigue estando sujeto a las mismas reglas de producer de OSIRIS que cualquier otra fuente:

es de solo lectura y no debe mutar infraestructura
no debe adivinar valores desconocidos
debe producir una salida determinista para la misma entrada de origen
debe eliminar secretos y fallar de forma segura cuando se detecten datos sensibles
debe validar mediante la CLI canonica de OSIRIS en lugar de entregar su propio validador alternativo

Esa disciplina importa aun mas en Cisco porque el panorama de origen es amplio. Sin un contrato estricto para producers, los exporters de APIC, NX-OS e IOS derivarian hacia tres interpretaciones incompatibles del mismo estandar.

Por que Cisco es una familia de producers significativa para OSIRIS

Cisco cubre fabrics dirigidos por controladores, switching de datacenter, routing, campus y escenarios de borde industrial. Eso lo convierte en una prueba de esfuerzo util para el modelo de producers de OSIRIS.

Si el estandar puede representar abstracciones de APIC, fabrics de NX-OS y bordes de red con IOS dentro de un unico enfoque coherente de intercambio, entonces esta demostrando algo importante: OSIRIS no sirve solo para un estilo de infraestructura. Realmente es capaz de abarcar los entornos mixtos que los operadores tienen que documentar y validar en el mundo real.

Leer la documentacion relacionada

Todos los nombres de productos y empresas son marcas comerciales™ o marcas registradas® de sus respectivos titulares. Su uso no implica ninguna afiliacion ni respaldo por parte de ellos.

OSIRIS JSON para Cisco APIC, NX-OS e IOS