OSIRIS JSON for Cisco

Cisco is not one producer target. It is several different infrastructure surfaces that need to converge into one portable model.

That is exactly why Cisco is an important OSIRIS JSON direction. A producer for Cisco APIC, Cisco NX-OS, and Cisco IOS should not flatten those worlds into the same raw export. It should translate each of them into a shared topology language while preserving the vendor-specific details that still matter downstream.

Three Cisco surfaces, one interchange goal

The producer challenge is different in each case.

• Cisco APIC exposes a controller and policy-driven fabric view
• Cisco NX-OS exposes device-centric datacenter switching inventory and relationships
• Cisco IOS exposes classic routing, access, and campus network state

Those are not interchangeable source models, but they can still feed the same OSIRIS document structure. That is the point of the standard: normalize heterogeneous infrastructure without pretending the sources were identical.

APIC should not be forced into a generic switch export

Cisco APIC is the clearest example of why OSIRIS needs both core fields and vendor namespaces.

An APIC-backed producer is not just discovering standalone devices. It is dealing with fabric-level constructs, policy boundaries, and controller-mediated relationships. In OSIRIS terms, that means a producer can still emit portable resources, groups, and connections for the graph that generic consumers need, while preserving ACI-specific semantics under the Cisco extension space.

The specification already leaves room for that direction through namespaced Cisco extensions and vendor-specific types such as osiris.cisco.aci.fabric. That is the right place for ACI-native meaning that should not be forced into the core schema.

NX-OS is a strong fit for core topology

Cisco NX-OS is a very natural producer target for OSIRIS because the underlying infrastructure already maps cleanly to the standard model.

Nexus fabrics typically revolve around switch resources, interfaces, uplinks, peerings, VLANs, routing context, and explicit physical or logical relationships. Those are the exact kinds of structures OSIRIS is built to carry. A good NX-OS producer should be able to emit:

• network.switch resources for Nexus devices
• deterministic IDs and stable provider attribution using cisco
• explicit connections for links, peerings, and attachment paths
• groups for fabric, site, rack, pod, or environment boundaries
• portable properties for model, management IP, version, and interface-level context

If a Cisco producer cannot express a switch fabric clearly in OSIRIS, the issue is not the domain. It is the producer.

IOS matters because the network edge still matters

Cisco IOS may look less fashionable than controller-driven fabrics, but it is still essential for the OSIRIS producer story.

Routers, branch devices, access-layer equipment, and legacy but critical network edges are exactly the kinds of systems that tend to live outside polished topology pipelines. OSIRIS needs to handle those environments too.

The standard already has straightforward mappings for common IOS-style infrastructure such as network.router, network.switch, network.vlan, and the relationships around them. That makes IOS a strong example of the producer principle that matters most in practice: normalize the portable shape first, then preserve vendor-native context where needed.

Cisco-specific detail without losing interoperability

Across APIC, NX-OS, and IOS, the producer rule stays the same: keep core topology portable, keep Cisco semantics namespaced.

That means:

• use standard OSIRIS resource and connection types when they already express the concept
• keep provider attribution stable with canonical Cisco naming
• store intrinsic, broadly useful attributes in properties
• store Cisco-native structures in extensions, using namespaces like osiris.cisco
• preserve deeper ACI-specific semantics under dedicated Cisco extension or vendor-type patterns rather than leaking them into the core model

This is where OSIRIS is stronger than ad-hoc exports. A consumer that knows nothing about Cisco should still be able to build the graph. A Cisco-aware consumer can then go deeper without breaking portability for everyone else.

The producer contract still applies

A Cisco producer is still bound by the same OSIRIS producer rules as every other source:

• it is read-only and must not mutate infrastructure
• it must not guess unknown values
• it must produce deterministic output for the same source input
• it must strip secrets and fail safely when sensitive data is detected
• it must validate through the canonical OSIRIS CLI instead of shipping its own competing validator

That discipline matters even more for Cisco because the source landscape is broad. Without a strict producer contract, APIC, NX-OS, and IOS exporters would drift into three incompatible interpretations of the same standard.

Why Cisco is a meaningful producer family for OSIRIS

Cisco covers controller-driven fabrics, datacenter switching, routing, campus, and industrial edge scenarios. That makes it a useful stress test for the OSIRIS producer model.

If the standard can represent APIC abstractions, NX-OS fabrics, and IOS network edges within one coherent interchange approach, then it is proving something important: OSIRIS is not just for one infrastructure style. It is actually capable of spanning the mixed environments that operators have to document and validate in the real world.

Read the related docs

• Read the producer guidelines
• Read the producer SDK internals
• Read the extension mechanism chapter
• Read the resource taxonomy chapter
• Read the producer editorial

All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.