Cisco Nexus 9300 NX-OS Mode vs ACI Mode: Which to Choose Before You Order
Cisco Nexus 9300 switches run either Cisco NX-OS or Cisco ACI, and the two modes are mutually exclusive boot images on the same hardware. NX-OS mode keeps every switch a standalone device that your team configures directly, usually in a VXLAN EVPN or classic Layer 2/3 design. ACI mode hands the whole leaf-spine fabric to a cluster of APIC controllers that push policy to every switch. Ports, optics, and cabling are identical in both modes; what changes is who owns the configuration, what the bill of materials contains, and which skills the team needs.
The short decision rule:
- Choose NX-OS mode for standards-based fabrics: VXLAN BGP EVPN or classic Layer 2/3 designs, infrastructure-as-code automation, and skills that carry across platforms and vendors.
- Choose ACI mode when centralized application policy is the requirement: zero-trust microsegmentation at scale, deep VMM integration with a large virtualization estate, multi-tenant fabrics, or consistency with an ACI footprint you already operate.
Two facts from Cisco’s current documentation reframe the old either/or debate. First, current data center networking (DCN) subscription licenses include both the ACI and NX-OS feature sets, so the software subscription no longer locks in a mode. Second, Nexus Dashboard now manages ACI and NX-OS fabrics from a single console. Hardware is the constraint that remains: ACI support varies by exact model across the current Nexus 9300 portfolio, so the mode decision belongs in the design phase, before the purchase order is cut.
What Changes When the Same Switch Boots NX-OS or ACI
The two modes are separate software images, not feature toggles. In NX-OS mode the switch boots an nxos image from its own bootflash and keeps a local configuration that you edit directly. In ACI mode the switch boots an ACI image distributed by the APIC cluster, registers with fabric discovery, and receives its entire operating state as policy from the controllers. Cisco’s upgrade documentation calls the first option NX-OS (standalone) mode, and standalone is the operative word: an NX-OS switch is a complete network device on its own, while an ACI switch is a managed element of a larger system.
Daily operations follow from that split. An NX-OS team configures interfaces, VLANs, VRFs, and BGP EVPN per device, or pushes templated configuration from Nexus Dashboard and its automation pipeline. An ACI team defines application profiles, endpoint groups, and contracts on the APIC, and the controllers program every leaf and spine; engineers still log in to a switch to verify state and troubleshoot, but configuration lives on the controller. If the ACI policy model is unfamiliar, our explainer on what Cisco ACI is and how its architecture works covers APIC, endpoint groups, and contracts in detail.
The physical platform is the part that never changes. Ports, ASICs, optics, and cabling are identical in both modes; software, licensing, and daily operations carry all of the difference.
NX-OS vs ACI: Differences That Decide the Choice
| Decision area | NX-OS mode | ACI mode |
|---|---|---|
| Configuration model | Per switch: CLI, NX-API, Ansible/Terraform, Nexus Dashboard templates | Central policy on the APIC cluster; controllers program all switches |
| Fabric design | VXLAN BGP EVPN or conventional L2/L3, standards-based | Cisco-managed VXLAN fabric driven by the ACI policy model |
| Required components | Switches only; management platforms optional | APIC controller cluster is mandatory |
| Segmentation | VRFs, ACLs, VXLAN group policy (GPO) | Endpoint groups and contracts; zero-trust microsegmentation |
| Multi-data-center | EVPN multi-site designs | Multi-Pod in the Essentials tier; Multi-Site requires Advantage plus Nexus Dashboard |
| Automation style | Infrastructure-as-code against device or controller APIs | Object-model API on APIC; network-as-code against one endpoint |
| Skills profile | Standard routing and switching, transferable across vendors | ACI-specific operational model and troubleshooting |
| Visibility and operations | Nexus Dashboard | APIC plus Nexus Dashboard |
Read the license tiers precisely before weighing the architecture debate. Cisco’s current DCN licensing tables place VXLAN BGP EVPN inside the NX-OS Essentials tier, so a standards-based fabric needs no premium license. On the ACI side, Multi-Pod ships in Essentials while Multi-Site requires Advantage. Tier boundaries like these decide real budgets more often than the headline architecture question does.
The strategic backdrop matters too. Cisco’s Nexus One solution overview, updated June 2026, describes ACI’s innovations being standardized through the IETF on top of VXLAN EVPN, with Nexus Dashboard providing unified operations across NX-OS VXLAN EVPN, ACI, and SONiC fabrics, including Layer 2, Layer 3, and security policies stretched across those environments side by side. Cisco cites more than 13,000 ACI customers, and both paths remain fully supported and actively developed. For a buyer, the practical reading is that the management plane no longer forces the choice; the configuration ownership model still does.
Which Mode Fits Which Environment
NX-OS mode is the stronger fit when:
- The design is a VXLAN EVPN fabric or a conventional aggregation layer, and the protocols underneath should stay standard and portable.
- Automation already runs through infrastructure-as-code toolchains, so a controller-specific object model would add a layer without adding capability.
- Operations staff rotate across campus, WAN, and data center roles, and standard routing and switching skills need to transfer.
- A future multivendor leaf-spine option matters commercially, because EVPN interoperates where ACI does not.
ACI mode earns its added components when:
- Segmentation policy is the core deliverable: multi-tenant fabrics, regulated environments, or zero-trust projects where endpoint groups and contracts replace hundreds of hand-maintained ACLs.
- A large virtualization or container estate will genuinely use VMM integration with VMware, Kubernetes, OpenShift, or Nutanix to keep network policy synchronized with workloads.
- Several sites must share one policy model, which is exactly the job of Multi-Pod and Multi-Site.
- An ACI estate already exists, and operational consistency across pods outweighs architectural novelty in the next procurement cycle.
Neither mode is a universal winner, and the failure modes are symmetrical. Teams pick ACI because SDN sounds strategic, then run it as a box-by-box network through the GUI; teams pick NX-OS because the CLI is familiar, then hand-build the segmentation matrix that contracts would have generated. Match the mode to the operating model your team will genuinely run.
Which Nexus 9300 Models Support ACI
Every current Nexus 9300 runs NX-OS. Not every current Nexus 9300 runs ACI. Cisco’s Nexus 9000 models-comparison page lists different supported software by category (checked July 2026):
| Nexus 9300 category | Supported operating modes |
|---|---|
| 800G leaf/spine switches | Cisco NX-OS |
| 800G scale-across universal spine / DCI (deep buffer) | Cisco ACI, NX-OS |
| 400G switches | Cisco ACI or NX-OS |
| 40/100G switches | Cisco ACI, NX-OS, or Nexus Hyperfabric |
| 1/10/25/50G fiber switches | Cisco ACI, NX-OS, Hyperfabric, or SONiC |
| 1/10GBASE-T switches | Cisco ACI, NX-OS, Hyperfabric, or SONiC |
Treat the table as a category map and verify the exact product ID. Cisco’s NX-OS-to-ACI conversion guide points to the Supported Hardware section of the ACI-mode release notes for the target release, and that check is per PID. The same guide carries two hardware caveats that belong in the ordering conversation: switches with only 16 GB of memory need a RAM upgrade before they can run ACI mode, and on modular platforms line cards are incompatible between the two boot modes. If the Nexus 9300 branch itself is still open, our Nexus 9000 series selection guide walks the family-level decision, including the 800G branches where the ACI answer differs.
What Each Mode Adds to the BOM: APIC, Licenses, Management
An NX-OS build is commercially simple: switches, optics, and a DCN license tier per switch. Essentials covers VXLAN EVPN fabrics; Advantage adds SR-MPLS, tenant routed multicast, and similar features. Current Nexus 9300 data sheets state that Nexus Dashboard is included with the tiered switch licenses, so the management platform usually adds nothing to the hardware quote.
An ACI build wraps mandatory components around the same switches:
| BOM line | NX-OS mode | ACI mode |
|---|---|---|
| Switch hardware | Nexus 9300 per design | Same, restricted to ACI-supported PIDs |
| Controllers | None required | APIC cluster: APIC-CLUSTER-M4 (three appliances, up to 1,200 edge ports) or APIC-CLUSTER-L4 (three appliances, above 1,200); virtual APIC options exist for small fabrics |
| Software license | DCN tier per switch | DCN tier per switch, applied to every device in the fabric, leaf and spine |
| Multi-DC add-ons | EVPN multi-site within NX-OS tiers | Multi-Site requires Advantage or Premier plus Nexus Dashboard Orchestrator |
| Encryption | MACsec per platform support | MACsec/CloudSec add-on licenses per device |
The most useful licensing fact sits in Cisco’s ACI ordering guide, updated June 30, 2026: current DCN subscription SKUs include both the Cisco ACI and Cisco NX-OS feature sets. A subscription customer licenses a tier and a platform class; either mode runs under that license, so the software spend survives a later change of direction. Perpetual licensing is narrower. For ACI it exists only at the Advantage tier, it is not portable between devices, and Premier is available only as a subscription. The same ordering guide states that licenses are required for both leaf and spine switches, which contradicts the widespread belief that spine switches ride along unlicensed.
Two consequences follow for the quote. First, the APIC cluster is the real cost delta between the modes, because per-switch licenses converge under subscription. Second, license SKUs are keyed to platform classes (1G, 10/25/40/100G, 400G-class, modular), so each license line must match the exact switch PID. Price the Nexus 9300 configuration with the mode already decided, and if an ACI or EVPN bill of materials deserves a second pair of eyes, send us the design and we will check the line items against it.
Converting Between Modes Later: What It Really Costs
Cisco supports conversion in both directions, and both directions are disruptive enough to plan as migration work inside a maintenance window.
NX-OS to ACI. Cisco’s current conversion procedure sets three prerequisites: the hardware must appear in the ACI-mode release notes, EPLD firmware must be current, and an APIC must be reachable, because the ACI image is copied from the APIC to the switch over SCP. The switch then boots the ACI image and joins fabric discovery. The standing NX-OS configuration is discarded by design, since policy now comes from the controllers. One sequencing rule deserves attention: save the configuration before the boot aci command, never after it, or the switch drops to the loader prompt.
ACI to NX-OS. The reverse path runs through the loader prompt and an init system step that repartitions the bootflash and erases the configuration, followed by roughly 15 to 20 minutes of waiting for system controllers on the first NX-OS boot. Plan a full rebuild of the standalone configuration, because nothing translates back. For a switch that shipped with NX-OS licenses preinstalled, Cisco’s multi-image boot document recommends copying the license file off-box before the ACI image ever boots, so it can be restored later.
A realistic conversion budget therefore includes an outage per switch, engineering time to rebuild configuration, possible RAM upgrades on 16 GB units, and lab validation of the target release. Teams migrating a whole estate usually stand up the new-mode fabric beside the old one and move workloads across. All of this cost is avoidable at order time: decide the mode first, then let the selection guide and the per-PID datasheet confirm the hardware.
FAQ
Which mode does a new Nexus 9300 ship in? The image is an ordering choice. On models covered by Cisco’s multi-image document, the factory loads your requested current image plus a long-lived image of the other OS type on the same switch. Confirm the shipping image for your exact PID when you order, and state the intended mode on the purchase order so licensing and APIC hardware land in the same quote.
Can NX-OS and ACI switches be mixed in one fabric? Not within a single fabric: an ACI fabric consists of ACI-mode switches under an APIC cluster. Separate NX-OS and ACI fabrics can run side by side under one Nexus Dashboard, and Cisco’s current architecture supports stretching connectivity and security policy across them, which is the practical route for gradual migrations.
Do you need to rebuy licenses to move between modes? Under current DCN subscriptions, no: the SKUs include both ACI and NX-OS feature sets. Perpetual licenses are mode-specific; Cisco publishes NX-OS-to-ACI perpetual upgrade SKUs, and Premier is subscription-only. Check the tier you actually need in the target mode, since features such as ACI Multi-Site sit above Essentials.
