Nexus: What Goes Where

Author
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:

Product

Spine

Leaf

Border- Leaf

RR Minimum Code Version

Nexus 6001 Series switch

Yes

Yes

Yes

Yes

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

Nexus 6004 Series switch

Yes

Yes

Yes

Yes

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

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

 

 

Yes

 

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

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

 

 

Yes

 

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. 

ACI

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

DFA: http://www.cisco.com/c/en/us/solutions/data-center-virtualization/unified-fabric/dynamic_fabric_automation.html#~Products

ACI: http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html

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. http://www.cisco.com/c/en/us/td/docs/switches/datacenter/dfa/solution/guide/b-dfa-solution-/b-dfa-solution_chapter_010.pdf
    This April 1 2014 document you listed indicates DFA 1 supports spines only for 7X00 and doesn’t mention F3 in its table. http://www.cisco.com/c/en/us/td/docs/switches/datacenter/dfa/release/notes/dfa-1-0-release-notes.html

  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

 

Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.

 

Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.

 

John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.