OSIRIS JSON fur Cisco

Cisco ist nicht ein einziges Producer-Ziel. Es sind mehrere unterschiedliche Infrastrukturflachen, die in einem einzigen portablen Modell zusammenlaufen mussen.

Genau deshalb ist Cisco eine wichtige Richtung fur OSIRIS JSON. Ein Producer fur Cisco APIC, Cisco NX-OS und Cisco IOS sollte diese Welten nicht in denselben Rohexport abflachen. Er sollte jede davon in eine gemeinsame Topologiesprache ubersetzen und dabei die vendorspezifischen Details erhalten, die nachgelagert weiterhin wichtig sind.

Drei Cisco-Oberflachen, ein Austauschsziel

Die Producer-Herausforderung ist in jedem Fall unterschiedlich.

Cisco APIC stellt eine controller- und richtliniengesteuerte Fabric-Sicht bereit
Cisco NX-OS stellt geraetezentriertes Datacenter-Switching-Inventar und entsprechende Beziehungen bereit
Cisco IOS stellt klassischen Routing-, Access- und Campus-Netzwerkzustand bereit

Das sind keine austauschbaren Quellmodelle, aber sie konnen dennoch dieselbe OSIRIS-Dokumentstruktur speisen. Genau darum geht es bei dem Standard: heterogene Infrastruktur normalisieren, ohne so zu tun, als seien die Quellen identisch.

APIC sollte nicht in einen generischen Switch-Export gezwungen werden

Cisco APIC ist das klarste Beispiel dafur, warum OSIRIS sowohl Core-Felder als auch Vendor-Namespaces braucht.

Ein APIC-gestutzter Producer entdeckt nicht nur eigenstandige Gerate. Er arbeitet mit Fabric-Konstrukten, Richtliniengrenzen und controllervermittelten Beziehungen. In OSIRIS-Begriffen bedeutet das, dass ein Producer weiterhin portable Ressourcen, Gruppen und Verbindungen fur den Graphen ausgeben kann, den generische Consumer brauchen, und gleichzeitig ACI-spezifische Semantik im Cisco-Erweiterungsraum bewahrt.

Die Spezifikation lasst fur diese Richtung bereits Raum durch Cisco-Erweiterungen mit Namespace und vendorspezifische Typen wie osiris.cisco.aci.fabric. Genau dort gehort ACI-native Bedeutung hin, die nicht in das Core-Schema gezwungen werden sollte.

NX-OS passt stark zur Core-Topologie

Cisco NX-OS ist ein sehr naturliches Producer-Ziel fur OSIRIS, weil sich die zugrunde liegende Infrastruktur bereits sauber auf das Standardmodell abbilden lasst.

Nexus-Fabrics drehen sich typischerweise um Switch-Ressourcen, Schnittstellen, Uplinks, Peerings, VLANs, Routing-Kontext und explizite physische oder logische Beziehungen. Genau diese Arten von Strukturen soll OSIRIS transportieren. Ein guter NX-OS-Producer sollte Folgendes ausgeben konnen:

network.switch-Ressourcen fur Nexus-Gerate
deterministische IDs und stabile Provider-Zuordnung mit cisco
explizite Verbindungen fur Links, Peerings und Attachment-Pfade
Gruppen fur Fabric-, Site-, Rack-, Pod- oder Umgebungsgrenzen
portable Eigenschaften fur Modell, Management-IP, Version und Kontext auf Schnittstellenebene

Wenn ein Cisco-Producer eine Switch-Fabric nicht klar in OSIRIS ausdrucken kann, liegt das Problem nicht in der Domain. Es liegt im Producer.

IOS ist wichtig, weil der Netzwerk-Edge weiter wichtig ist

Cisco IOS mag weniger modern wirken als controllergesteuerte Fabrics, ist fur die OSIRIS-Producer-Story aber weiterhin essenziell.

Router, Branch-Gerate, Access-Layer-Ausrustung und alte, aber kritische Netzwerk-Edges sind genau die Art von Systemen, die meist ausserhalb sauberer Topologie-Pipelines leben. OSIRIS muss auch diese Umgebungen abdecken.

Der Standard hat bereits direkte Abbildungen fur ubliche IOS-artige Infrastruktur wie network.router, network.switch, network.vlan und die dazugehorigen Beziehungen. Damit ist IOS ein starkes Beispiel fur das Producer-Prinzip, das in der Praxis am wichtigsten ist: zuerst die portable Form normalisieren und dann, wo notig, den nativen Vendor-Kontext bewahren.

Cisco-spezifische Details ohne Verlust der Interoperabilitat

Uber APIC, NX-OS und IOS hinweg bleibt die Producer-Regel gleich: die Core-Topologie portabel halten und die Cisco-Semantik in Namespaces halten.

Das bedeutet:

standardisierte OSIRIS-Ressourcen- und Verbindungstypen verwenden, wenn sie das Konzept bereits ausdrucken
die Provider-Zuordnung mit kanonischer Cisco-Benennung stabil halten
intrinsische, breit nutzliche Attribute in properties speichern
Cisco-native Strukturen in extensions speichern und dabei Namespaces wie osiris.cisco verwenden
tiefere ACI-spezifische Semantik unter dedizierten Cisco-Erweiterungs- oder Vendor-Typ-Mustern bewahren, statt sie in das Core-Modell auslaufen zu lassen

Hier ist OSIRIS starker als Ad-hoc-Exporte. Ein Consumer, der nichts uber Cisco weiss, sollte den Graphen trotzdem aufbauen konnen. Ein Cisco-bewusster Consumer kann dann tiefer gehen, ohne die Portabilitat fur alle anderen zu brechen.

Der Producer-Vertrag gilt weiterhin

Ein Cisco-Producer unterliegt weiterhin denselben OSIRIS-Producer-Regeln wie jede andere Quelle:

er ist schreibgeschutzt und darf Infrastruktur nicht verandern
er darf unbekannte Werte nicht erraten
er muss fur dieselbe Quell-Eingabe deterministische Ausgabe erzeugen
er muss Geheimnisse entfernen und sicher fehlschlagen, wenn sensible Daten erkannt werden
er muss uber die kanonische OSIRIS-CLI validieren, statt einen eigenen konkurrierenden Validator mitzuliefern

Diese Disziplin ist bei Cisco noch wichtiger, weil die Quellenlandschaft breit ist. Ohne einen strikten Producer-Vertrag wurden APIC-, NX-OS- und IOS-Exporter in drei inkompatible Interpretationen desselben Standards auseinanderdriften.

Warum Cisco eine bedeutende Producer-Familie fur OSIRIS ist

Cisco deckt controllergesteuerte Fabrics, Datacenter-Switching, Routing, Campus- und Industrial-Edge-Szenarien ab. Das macht Cisco zu einem nutzlichen Hartutest fur das OSIRIS-Producer-Modell.

Wenn der Standard APIC-Abstraktionen, NX-OS-Fabrics und IOS-Netzwerk-Edges in einem einzigen koharenten Austauschsansatz darstellen kann, dann beweist er etwas Wichtiges: OSIRIS ist nicht nur fur einen Infrastrukturstil gedacht. Es ist tatsachlich in der Lage, die gemischten Umgebungen abzudecken, die Betreiber in der realen Welt dokumentieren und validieren mussen.

Zugehorige Dokumente lesen

Alle Produkt- und Unternehmensnamen sind Marken™ oder eingetragene Marken® ihrer jeweiligen Inhaber. Ihre Verwendung impliziert keinerlei Verbindung zu ihnen und keine Unterstutzung durch sie.

OSIRIS JSON fur Cisco APIC, NX-OS und IOS