Nexus: What Goes Where

Peter Welcher
Architect, Operations Technical Advisor

20140304-fig01The Cisco announcement last November of Insieme ACI and Nexus 9K hardware gave us a plethora of choices, and left many wonder what Nexus box they should use, and where. It behooves us all to understand the Cisco Nexus product positioning, since they aren’t cheap, and we don’t want to paint ourselves into a corner with the wrong purchase. That’s particularly important for consultants and Cisco resellers providing purchasing recommendations. This blog lays out the major considerations in picking which Nexus platform to buy, and where to use it in your datacenter. 

Cisco Nexus Positioning

What I’ve seen or heard to date depends to some extent on intended use. For the top of the datacenter hierarchy:

  • N7K or N9K for Core/Backbone
  • N9K, N6K, or N7K for Aggregation/Spine. Use N6K/N7K if you want FCoE/SAN/convergence. (N9K doesn’t do SAN, won’t in the near term)

For access:

  • Either N2K + N9K or N2K + N5K/N7K for Enterprise / private cloud settings
  • N2K/5K/7K access 

For HFT (High Frequency Trading) environments: N6K/N9K aggregation, N3K/N9K access

One can add more nuances and details to this, but I’m trying to keep this fairly simple. The other factor to bear in mind is functionality. The N9K runs a reduced NX-OS image. Make sure the features supported align with your design plans!

Management Approaches

You can also come at this topic via the management approach you plan to use. You get three choices:

  • Classic CLI (or DCNM): classic!
  • DFA (Dynamic Fabric Automation): released first version at the end of January 2014
  • ACI (Application Centric Infrastructure): coming soon

Here’s why your choice matters:

  • If you’re happy with the NX-OS CLI, then speeds / feeds / features are probably what you most care about. View the N9K as a fast, low cost switch with many but not all Nexus features. Use the N6K or N7K as a very functional core, use the N9K in pods. But if you think you might want to try or shift to ACI at some future date, see the ACI readiness notes below.  
  • If you want to try automation but in a more incremental fashion, DFA might be for you. You’ll need to plan your hardware around DFA-readiness. See the DFA requirements below.
  • If you love the idea of ACI, and can’t wait for it to be released, are ready to work with not-yet-mature hardware and software, etc., then ACI-readiness probably matters to you. Or if you think you might want ACI in a year or so, when the new product bugs are sorted out. Either way, see the ACI readiness notes below

DFA Requirements

I found a table of DFA platform requirements in several places:

Here’s my version:




Border- Leaf

RR Minimum Code Version

Nexus 6001 Series switch





Cisco NX-OS Release 7.0(0)N1(1)

Nexus 6004 Series switch





Cisco NX-OS Release 7.0(0)N1(1)

Nexus 7000 Series switch
(F2, F2E, or F3 module)





Cisco NX-OS Release 6.2(2)
(or perhaps 6.2(6)?)

Nexus 7700 Series switch
(F2, F2E, or F3 module)





Cisco NX-OS Release 6.2(2)
(or perhaps 6.2(6)?)

Nexus 1000V switch for VMware vSphere 5.1 and 5.5: virtual switch, VDP signaling





Cisco NX-OS Release 4.2(1)SV2(2.2)

As best I can tell from what’s online (and I double-checked), the N7K F2 and F3 line cards do support DFA in a Border-Leaf role. The Border-Leaf role is what connects to the rest of the datacenter and the outside world. Based on a posted Cisco whitepaper, the F3 card plus future software may support Nexus 7000 as a Leaf node.

RR means can act as BGP Route Reflector. At least one is required.

The N5K fits in as a L2-only (limited) Leaf. That is, you can make it fit in, it’ll partly participate in DFA. (Or that’s how I’m understanding it.)

Short version of all this: if you really want to do full DFA right now, you’ll need N6K hardware. See your Cisco account team for roadmap / future features. I wouldn’t be surprised to see a Nexus code update for the N7K broaden its role (and I 

DFA Software

DFA requires Cisco Prime Data Center Network Manager (DCNM) Essentials, version 7.0. If you are running “Classic” DCNM, you do not want 7.0, you want the latest 6.x release. The two software trains will merge at some point, but are not yet equivalent in terms of functionality.

DFA uses Cisco Prime Network Services Controller (NSC), release 3.2. 

It also comes with its own OpenStack controller (optional): OpenStack for Cisco DFA 1.0. 


The N9K hardware supports either NX-OS mode (Classic but limited NX-OS), or ACI mode (coming).

The Nexus 9500 platform currently has the following line cards. Note that two have limitations.

  • Nexus 9500: 36 x 40 G QSFP  linecard: NX-OS-only, no ACI
  • Nexus 9500: 48 x 1/10 G SFP+ + 4 x 40 G QSFP+ line card: OK for ACI leaf, can do FEX support
  • Nexus 9500: 48 x 100M/1/10 G 10GBASE-T + 4 x 40 G QSFP+ line card: OK for ACI leaf
  • Nexus 9500: 36 x 40 G QSFP+ ACI-only Spine line card [COMING]

The Nexus 9300 switches will be capable of being used in ACI Leaf roles.

Related Links



Hashtags: #Nexus #datacenter #ACI #DFA #automation

Twitter: @pjwelcher

Disclosure Statement

ccie_15years_med CiscoChampion200PX

2 responses to “Nexus: What Goes Where

  1. Based on Cisco’s documentation listed one would have to conclude that as of 4-1-2014 7X00 supports spine only and no leaf functions. The table in the following URL that you posted contradicts your table indicating that 7X00 switches can be spines only and not leaf nodes.
    This April 1 2014 document you listed indicates DFA 1 supports spines only for 7X00 and doesn’t mention F3 in its table.

  2. Thanks for the comments Micah. I always appreciate critical reading, I’m quite capable of error.

    Looking at the table at the top of your first URL, I’m only seeing "yes" in the Spine column next to the two N7K rows (and the RR column, but that’s Route Reflector). The second URL says spines only, and says F2, F2E in one row and that plus F3 in another (newer NXOS code). Which is what footnote 1 in the first URL says. A note in the second doc says F3 requires MPLS license for now, requirement to be removed later. So what Cisco’s put out seems pretty consistent and the way I’m reading it, agrees with what I wrote.

    Hey, it could be a lot worse. I just spent a too much time trying to find out which routers support EIGRP OTP, found almost nothing, and what I found is very inconsistent (doc says ISR G2 supports it, Feature Navigator fails to show that).

Leave a Reply