Nexus 9300 Leaf Selection Checklist: NICs, Media, Modes and Fabric Services

Use this checklist to determine whether a candidate Nexus 9300 configuration can perform a defined leaf role. The series name is not a complete specification: interface layout, supported modes, software and workload features must be established for the exact model.

1. Document server attachment

Create one row per server-interface class. Record NIC model, supported rate, copper or pluggable media, host software and redundancy arrangement. Include actual cable routes and the peer ports required by the design.

Do not treat a copper port and an optical port at the same rate as interchangeable. For pluggable links, select the actual optical or cable implementation and verify host support at both ends. R25R49

2. Separate access and uplink budgets

Count usable logical ports in the required modes, then allocate them to hosts, uplinks and named expansion. Record any restrictions associated with breakout or mixed-rate operation.

For an illustrative budget, thirty-two 100G host links total 3.2 Tb/s of nominal access capacity. Eight 400G uplinks total the same amount; losing one leaves 2.8 Tb/s. This arithmetic describes a planning state, not guaranteed application throughput or unrestricted internal forwarding capacity.

3. Map features to a documented platform baseline

Requirement	Evidence and test
VLAN and routed access	Supported configuration and expected endpoint reachability
Link aggregation or dual attachment	Exact topology support and failure behavior
VXLAN/EVPN	Supported features, scale and control-plane design
RoCE	Applicable queue, congestion and flow-control behavior
Monitoring	Required counters, logs and operational access

VXLAN encapsulation and EVPN control-plane behavior are distinct design elements. Confirm the actual functions needed rather than accepting an undifferentiated “VXLAN supported” statement. R30R31

For RoCE, use platform- and release-specific guidance. High bandwidth or a generic PFC feature does not establish a complete RDMA deployment. R24

4. Verify installation and support conditions

Record airflow, power input, mounting and service clearance. Confirm the exact software and entitlement requirements of the proposed deployment. Separate commercially available hardware from a configuration that has been qualified for the project.

A supplier’s alternative SKU should trigger a review of every changed dimension, not only the front-panel port count.

5. Run a staged acceptance sequence

First verify inventory, link mode and diagnostics. Then test basic forwarding and the required routing or overlay service. Add representative workload concurrency and inspect error and congestion observations. Finally, test the approved fault scenario and compare application behavior with the requirement.

Retain host placement, traffic profile, versions and port map with the results. A same-rack host-pair test should not be presented as proof of cross-fabric scaling.

The completed checklist should identify approved requirements, unmet requirements and unresolved evidence. It provides a defensible comparison between candidate leaf configurations without assuming uniform capabilities across the entire Nexus 9300 family.

Engineering illustrations

These figures illustrate the design concepts discussed here. They are not measured results, certified configurations or a supplied-equipment list.

Related reading

• Nexus Leaf Design: Match Server Interfaces to Fabric Requirements
• Why More Bandwidth Alone Will Not Fix a RoCE Fabric

References

• R24: Nexus 9000 NX-OS 10.5(x): Configuring Priority Flow Control
• R25: Cisco 100GBASE QSFP Modules Data Sheet
• R49: Cisco transceiver-to-device compatibility matrix
• R30: RFC 7348: Virtual eXtensible Local Area Network (VXLAN)
• R31: RFC 8365: A Network Virtualization Overlay Solution Using EVPN; RFC 7432: BGP MPLS-Based EVPN