OSIRIS JSON per Cisco

Cisco non è un solo target di producer. È un insieme di aree infrastrutturali differenti che devono convergere in un unico modello portabile.

Ed è proprio per questo che Cisco rappresenta una scelta importante come primo producer per OSIRIS JSON. Un producer per Cisco APIC, Cisco NX-OS e Cisco IOS non dovrebbe appiattire questi scenari nello stesso export di dati grezzo. Dovrebbe tradurre ciascuno di essi in un linguaggio topologico condiviso, preservando al tempo stesso i dettagli vendor-specific.

Tre piattaforme Cisco, un unico obiettivo di interscambio

La sfida del producer è diversa in ogni caso.

Cisco APIC espone una vista di fabric guidata da controller e da policy
Cisco NX-OS espone inventario e relazioni di switching datacenter centrati sul dispositivo
Cisco IOS espone lo stato classico di routing, accesso o rete campus

Questi non sono modelli sorgente intercambiabili, ma possono comunque alimentare la stessa struttura documentale OSIRIS. Questo è il punto dello standard: normalizzare infrastrutture eterogenee senza pensare che le sorgenti siano identiche.

APIC non dovrebbe essere forzato in un export generico di switch

Cisco APIC è l’esempio più chiaro del perché OSIRIS abbia bisogno sia di campi core sia di namespace vendor.

Un producer basato su APIC non si limita a scoprire dispositivi standalone. Ha a che fare con costrutti a livello di fabric, confini di policy e relazioni mediate dal controller. In termini OSIRIS, questo significa che un producer può comunque emettere risorse, gruppi e connessioni portabili per la topologia di cui hanno bisogno i consumer generici, preservando al contempo la semantica specifica di ACI nello spazio di estensione Cisco.

La specifica lascia già spazio a questa direzione tramite estensioni Cisco con namespace e tipi vendor-specific come osiris.cisco.aci.fabric. Questo è il posto giusto per il significato nativo di ACI che non dovrebbe essere forzato nello schema core.

NX-OS è molto adatto alla topologia core

Cisco NX-OS è un target di producer molto naturale per OSIRIS perché l’infrastruttura sottostante si mappa già in modo pulito sul modello standard.

Le fabric Nexus ruotano tipicamente attorno a risorse switch, interfacce, uplink, peerings, VLAN, contesto di routing e relazioni fisiche o logiche esplicite. Questi sono esattamente i tipi di strutture che OSIRIS è progettato per trasportare. Un buon producer NX-OS dovrebbe essere in grado di emettere:

risorse network.switch per dispositivi Nexus
ID deterministici e attribuzione stabile del provider usando cisco
connessioni esplicite per link, peerings e percorsi di attachment
gruppi per confini di fabric, sito, rack, pod o ambiente
proprietà portabili per modello, management IP, versione e contesto a livello di interfaccia

IOS conta perché anche il bordo della rete conta

Cisco IOS può sembrare meno di moda rispetto alle fabric guidate da controller, ma resta essenziale per la storia dei producer OSIRIS.

Router, dispositivi branch, apparati di access layer e confini di rete legacy ma critici sono esattamente il tipo di sistemi che tendono a vivere fuori da pipeline topologiche curate. OSIRIS deve gestire anche questi ambienti.

Lo standard possiede già mapping diretti per infrastrutture comuni in stile IOS, come network.router, network.switch, network.vlan e le relazioni che ruotano intorno a esse. Questo rende IOS un forte esempio del principio di producer che conta di più nella pratica: normalizzare prima la forma portabile, poi preservare il contesto nativo del vendor dove serve.

Dettagli Cisco-specific senza perdere interoperabilità

Tra APIC, NX-OS e IOS, la regola del producer resta la stessa: mantenere la topologia core portabile, mantenere la semantica Cisco in namespace.

Questo significa:

usare tipi standard di risorsa e connessione OSIRIS quando esprimono già il concetto
mantenere stabile l’attribuzione del provider con naming Cisco canonico
archiviare attributi intrinseci e ampiamente utili in properties
archiviare strutture native di Cisco in extensions, usando namespace come osiris.cisco
preservare semantiche ACI più profonde sotto pattern dedicati di estensione Cisco o di vendor-type invece di farle trapelare nel modello core

È qui che OSIRIS è più forte rispetto agli export ad hoc. Un consumer che non sa nulla di Cisco dovrebbe comunque poter costruire la topologia. Un consumer consapevole di Cisco può poi andare più in profondità senza spezzare la portabilità per tutti gli altri.

Il contratto del producer continua a valere

Un producer Cisco resta vincolato dalle stesse regole dei producer OSIRIS di ogni altra sorgente:

è read-only e non deve modificare l’infrastruttura
non deve indovinare valori sconosciuti
deve produrre output deterministico a parità di input sorgente
deve rimuovere i secrets e fallire in modo sicuro quando rileva dati sensibili
deve validare tramite la CLI canonica di OSIRIS invece di distribuire un proprio validatore concorrente

Questa disciplina conta ancora di più per Cisco, perché il panorama delle sorgenti è ampio. Senza un contratto di producer rigoroso, gli exporter di APIC, NX-OS e IOS finirebbero per divergere in tre interpretazioni incompatibili dello stesso standard.

Perché Cisco è una famiglia di producer significativa per OSIRIS

Cisco copre fabric guidate da controller, switching datacenter, routing, campus e scenari di edge industriale. Questo la rende un utile stress test per il modello di producer OSIRIS.

Se lo standard riesce a rappresentare astrazioni APIC, fabric NX-OS e confini di rete IOS all’interno di un unico approccio coerente di interscambio, allora sta dimostrando qualcosa di importante: OSIRIS non è pensato per un solo stile infrastrutturale. È realmente capace di attraversare gli ambienti misti che gli operatori devono documentare e validare nel mondo reale.

Leggi la documentazione correlata

Tutti i nomi di prodotti e aziende sono marchi(TM) o marchi registrati(R) dei rispettivi titolari. Il loro utilizzo non implica alcuna affiliazione né alcuna approvazione da parte loro.

OSIRIS JSON per Cisco APIC, NX-OS e IOS