Nexus 9000 is a cost-effective and reliable platform. This is in the first place due to the take-out of a lot of advanced functions (or state this as: a lot of complexity), inherent to the Nexus 7000: VDC, FabricPath, OTV … To provide a given number of 1/10G endpoint connections, the CAPEX of the required Nexus 93xxx bundles in NX-OS mode, is easily 30-40% below that of a Nexus 7700/5600 DCN. And the Nx9K is ACI-capable … Hence, when legacy DCN components are subject to lifecycle replacement, several network managers consider to do a quick-win, by replacing legacy switches by Nx9K in NxOS mode (avoiding the cost of ACI license and APIC!). At the same time, they believe to convert to ACI later on, when a killing use case will justify SDN. While at first glance, this looks a fair approach, I don’t recommend it, for following reasons:
1) The dual transition incurring dual effort, cost and risk; first, from legacy to NxOS Nx9K, then Nx9K from NxOS to ACI
2) After a more or less intensive first transition effort, it is a human reaction to set back and relax, and eternally postpone any ACI conversion, unless a strong business case would appear
3) If there is no believe in SDN today, will there be believe in SDN later on? The decision on DCN technology has to be taken with future business requirements in mind. Does the company have insight in its future business requirements, and how they translate to IT Infrastructure (including DCN)?
4) Last but not least, the transition of Nx9K from NxOS mode to ACI mode is quite disruptive (see below).
For those organizations who do consider a NxOS-to-ACI transition of their Nx9K ballpark, there is a (lab!) scenario published as a Cisco Whitepaper:
http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-736866.html
A further thought is that the requirements calling for the Nx7K-specific functions (VDC, OTV, FabricPath), can be partly addressed by deploying Nx9K in NxOS mode as a VXLAN fabric, rather as a traditional bunch of VPC peers. But far more interestingly, all these requirements can be fulfilled at a far more level of abstraction by ACI. This is shown in the table below.
| requirement | Nx7000 | Nexus 9000 NxOS (VPC) | Nexus 9000 NxOS (VXLAN) | Nexus 9000 ACI |
| Separation | VDC | – | – | Tenants |
| Loop-free DC-wide Layer-2 domains | FabricPath | – | BGP fabric with VXLAN on top, all self-made | BGP fabric with VXLAN on top, automatically built by APIC |
| Layer-2 over DCI ‘better than dot1q trunk’ | OTV | – | EVPN | EVPN |
In conclusion I recommend all organizations facing a DCN lifecycle replacement to first consider their future business requirements. In this context, they should explore if ACI has a substantial value to address these requirements. In addition, they should check if there is a more fundamental business case favoring ACI: reduction of CAPEX (including deployment cost) and of recurring cost (operations, maintenance, adds-moves-changes, planned and unplanned downtime).µ
For those organizations not able to justify ACI, Nx9K in NxOS mode offers an excellent and cost-effective replacement of e.g. a classical Catalyst 6K or 4K DCN. For the small DCNs, a loop-free 2-tier VPC setup is proven and adequate. Where scalability and/or intelligent and secure stretching of Layer-2 domains over multiple DCs come around, a leaf-spine fabric with self-built BGP, VXLAN on top, and EVPN as DCI is an option. However one has to weight-out the complexity to implement and manage a self-built BGP/VXLAN fabric against the extra cost for ACI, where setup is plug-and-play and management is highly facilitated by the APIC controller.
Jan Devos Network Technology Blog 