OSIRIS JSON pour Cisco

Cisco n’est pas une seule cible producer. Ce sont plusieurs surfaces d’infrastructure differentes qui doivent converger vers un seul modele portable.

C’est exactement pour cela que Cisco constitue une direction importante pour OSIRIS JSON. Un producer pour Cisco APIC, Cisco NX-OS et Cisco IOS ne doit pas aplatir ces mondes dans une meme exportation brute. Il doit traduire chacun d’eux dans un langage de topologie partage tout en preservant les details specifiques au vendor qui comptent encore en aval.

Trois surfaces Cisco, un seul objectif d’echange

Le defi du producer est different dans chaque cas.

Cisco APIC expose une vue de fabric pilotee par controleur et par politiques
Cisco NX-OS expose un inventaire et des relations de switching de datacenter centres sur l’equipement
Cisco IOS expose l’etat classique du routage, de l’acces et des reseaux de campus

Ce ne sont pas des modeles source interchangeables, mais ils peuvent tout de meme alimenter la meme structure de document OSIRIS. C’est tout l’enjeu du standard: normaliser une infrastructure heterogene sans pretendre que les sources etaient identiques.

APIC ne doit pas etre force dans une exportation generique de switch

Cisco APIC est l’exemple le plus clair de la raison pour laquelle OSIRIS a besoin a la fois de champs core et de namespaces vendor.

Un producer adosse a APIC ne se contente pas de decouvrir des equipements autonomes. Il traite des constructions au niveau fabric, des frontieres de politiques et des relations mediees par le controleur. En termes OSIRIS, cela signifie qu’un producer peut toujours emettre des ressources, des groupes et des connexions portables pour le graphe dont les consumers generiques ont besoin, tout en preservant la semantique specifique a ACI dans l’espace d’extensions Cisco.

La specification laisse deja de la place a cette direction grace a des extensions Cisco avec namespace et a des types specifiques au vendor comme osiris.cisco.aci.fabric. C’est le bon endroit pour une signification native ACI qui ne doit pas etre forcee dans le schema core.

NX-OS correspond fortement a la topologie core

Cisco NX-OS est une cible producer tres naturelle pour OSIRIS parce que l’infrastructure sous-jacente se mappe deja proprement vers le modele standard.

Les fabrics Nexus s’articulent generalement autour de ressources de switch, d’interfaces, d’uplinks, de peerings, de VLAN, de contexte de routage et de relations physiques ou logiques explicites. Ce sont exactement les types de structures qu’OSIRIS est concu pour transporter. Un bon producer NX-OS doit pouvoir emettre:

des ressources network.switch pour les equipements Nexus
des ID deterministes et une attribution stable du provider en utilisant cisco
des connexions explicites pour les liens, les peerings et les chemins d’attachment
des groupes pour les frontieres de fabric, site, rack, pod ou environnement
des proprietes portables pour le modele, l’IP de gestion, la version et le contexte au niveau interface

Si un producer Cisco ne peut pas exprimer clairement une switch fabric dans OSIRIS, le probleme n’est pas le domaine. C’est le producer.

IOS compte parce que la peripherie reseau compte toujours

Cisco IOS peut sembler moins a la mode que les fabrics pilotes par controleur, mais il reste essentiel pour l’histoire des producers OSIRIS.

Les routeurs, les equipements de succursale, les equipements de couche d’acces et les peripheries reseau anciennes mais critiques sont exactement le type de systemes qui vivent en dehors de pipelines de topologie soigneusement polis. OSIRIS doit aussi gerer ces environnements.

Le standard dispose deja de mappings directs pour une infrastructure courante de style IOS telle que network.router, network.switch, network.vlan et les relations qui les entourent. Cela fait d’IOS un exemple fort du principe de producer le plus important en pratique: d’abord normaliser la forme portable, puis preserver le contexte natif du vendor quand c’est necessaire.

Des details specifiques a Cisco sans perdre l’interoperabilite

Dans APIC, NX-OS et IOS, la regle du producer reste la meme: garder la topologie core portable et garder la semantique Cisco dans des namespaces.

Cela signifie:

utiliser les types standard de ressources et de connexions OSIRIS lorsqu’ils expriment deja le concept
maintenir une attribution stable du provider avec une denomination canonique Cisco
stocker les attributs intrinseques et largement utiles dans properties
stocker les structures natives Cisco dans extensions, en utilisant des namespaces comme osiris.cisco
preserver une semantique ACI plus profonde sous des motifs dedies d’extension Cisco ou de type vendor au lieu de la laisser fuir dans le modele core

C’est la qu’OSIRIS est plus fort que les exportations ad hoc. Un consumer qui ne sait rien de Cisco doit quand meme pouvoir construire le graphe. Un consumer conscient de Cisco peut ensuite aller plus loin sans casser la portabilite pour tout le monde.

Le contrat du producer s’applique toujours

Un producer Cisco reste soumis aux memes regles de producer OSIRIS que toute autre source:

il est en lecture seule et ne doit pas modifier l’infrastructure
il ne doit pas deviner les valeurs inconnues
il doit produire une sortie deterministe pour une meme entree source
il doit supprimer les secrets et echouer de maniere sure lorsque des donnees sensibles sont detectees
il doit valider via la CLI canonique d’OSIRIS au lieu de livrer son propre validateur concurrent

Cette discipline compte encore davantage pour Cisco parce que le paysage des sources est large. Sans contrat producer strict, les exporters APIC, NX-OS et IOS deriveraient vers trois interpretations incompatibles d’un meme standard.

Pourquoi Cisco est une famille de producers significative pour OSIRIS

Cisco couvre les fabrics pilotes par controleur, le switching de datacenter, le routage, le campus et les scenarios de peripherie industrielle. Cela en fait un test de resistance utile pour le modele de producers OSIRIS.

Si le standard peut representer des abstractions APIC, des fabrics NX-OS et des peripheries reseau IOS dans une seule approche d’echange coherente, alors il prouve quelque chose d’important: OSIRIS n’est pas reserve a un seul style d’infrastructure. Il est reellement capable de couvrir les environnements mixtes que les operateurs doivent documenter et valider dans le monde reel.

Lire la documentation associee

Tous les noms de produits et d’entreprises sont des marques commerciales™ ou des marques deposees® de leurs detenteurs respectifs. Leur utilisation n’implique aucune affiliation ni aucun soutien de leur part.

OSIRIS JSON pour Cisco APIC, NX-OS et IOS