Cisco Data Center Spine-And-Leaf Architecture - Design Overview White Paper
Cisco Data Center Spine-And-Leaf Architecture - Design Overview White Paper
Cisco Data Center Spine-And-Leaf Architecture - Design Overview White Paper
Cisco public
Figure 1.
Traditional three-tier data center design
The architecture consists of core routers, aggregation routers (sometimes called distribution routers), and
access switches. Between the aggregation routers and access switches, Spanning Tree Protocol is used to
build a loop-free topology for the Layer 2 part of network. Spanning Tree Protocol provides several
benefits: it is simple, and it is a plug-and-play technology requiring little configuration. VLANs are
extended within each pod that servers can move freely within the pod without the need to change IP
address and default gateway configurations. However, Spanning Tree Protocol cannot use parallel
forwarding paths, and it always blocks redundant paths in a VLAN.
In 2010, Cisco introduced virtual-port-channel (vPC) technology to overcome the limitations of Spanning
Tree Protocol. vPC eliminates the spanning-tree blocked ports, provides active-active uplink from the
access switches to the aggregation routers, and makes full use of the available bandwidth, as shown in
Figure 2. With vPC technology, Spanning Tree Protocol is still used as a fail-safe mechanism.
vPC technology works well in a relatively small data center environment in which most traffic consists of
northbound and southbound communication between clients and servers.
Since 2003, with the introduction of virtual technology, the computing, networking, and storage resources
that were segregated in pods in Layer 2 in the three-tier data center design can be pooled. This
revolutionary technology created a need for a larger Layer 2 domain, from the access layer to the core
layer, as shown in Figure 3.
Figure 3.
Data center design with extended Layer 3 domain
With Layer 2 segments extended across all the pods, the data center administrator can create a central,
more flexible resource pool that can be reallocated based on needs. Servers are virtualized into sets of
virtual machines that can move freely from server to server without the need to change their operating
parameters.
A new data center design called the Clos network–based spine-and-leaf architecture was developed to
overcome these limitations. This architecture has been proven to deliver the high-bandwidth, low-latency,
nonblocking server-to-server connectivity.
Spine-and-leaf architecture
Figure 4 shows a typical two-tiered spine-and-leaf topology.
Figure 4.
Typical spine-and-leaf topology
In this two-tier Clos architecture, every lower-tier switch (leaf layer) is connected to each of the top-tier
switches (spine layer) in a full-mesh topology. The leaf layer consists of access switches that connect to
devices such as servers. The spine layer is the backbone of the network and is responsible for
interconnecting all leaf switches. Every leaf switch connects to every spine switch in the fabric. The path is
randomly chosen so that the traffic load is evenly distributed among the top-tier switches. If one of the top
tier switches were to fail, it would only slightly degrade performance throughout the data center.
If oversubscription of a link occurs (that is, if more traffic is generated than can be aggregated on the
active link at one time), the process for expanding capacity is straightforward. An additional spine switch
can be added, and uplinks can be extended to every leaf switch, resulting in the addition of interlayer
bandwidth and reduction of the oversubscription. If device port capacity becomes a concern, a new leaf
switch can be added by connecting it to every spine switch and adding the network configuration to the
switch. The ease of expansion optimizes the IT department’s process of scaling the network. If no
oversubscription occurs between the lower-tier switches and their uplinks, then a nonblocking architecture
can be achieved.
Overlay network
Modern virtualized data center fabrics must meet certain requirements to accelerate application
deployment and support DevOps needs. For example, fabrics need to support scaling of forwarding tables,
scaling of network segments, Layer 2 segment extension, virtual device mobility, forwarding path
optimization, and virtualized networks for multitenant support on shared physical infrastructure.
Although the concept of a network overlay is not new, interest in network overlays has increased in the
past few years because of their potential to address some of these requirements. Interest in overlay
networks has also increased with the introduction of new encapsulation frame formats specifically built for
the data center. These formats include Virtual Extensible LAN (VXLAN), Network Virtualization Using
Generic Routing Encapsulation (NVGRE), Transparent Interconnection of Lots of Links (TRILL), and
Location/Identifier Separation Protocol (LISP). Network overlays are virtual networks of interconnected
nodes that share an underlying physical network, allowing deployment of applications that require specific
network topologies without the need to modify the underlying network (Figure 5).
Figure 5.
Network overlay concept
● Optimized device functions: Overlay networks allow the separation (and specialization) of device
functions based on where a device is being used in the network. An edge or leaf device can
optimize its functions and all its relevant protocols based on end-state information and scale, and a
core or spine device can optimize its functions and protocols based on link-state updates,
optimizing with fast convergence.
● Fabric scalability and flexibility: Overlay technologies allow the network to scale by focusing scaling
on the network overlay edge devices. With overlays used at the fabric edge, the spine and core
devices are freed from the need to add end-host information to their forwarding tables.
● Overlapping addressing: Most overlay technologies used in the data center allow virtual network IDs
to uniquely scope and identify individual private networks. This scoping allows potential overlap in
MAC and IP addresses between tenants. The overlay encapsulation also allows the underlying
infrastructure address space to be administered separately from the tenant address space.
This document reviews several spine-and-leaf architecture designs that Cisco has offered in the recent
past as well as current designs and those the Cisco expects to offer in the near future to address fabric
requirements in the modern virtualized data center:
Each section outlines the most important technology components (encapsulation; end-host detection and
distribution; broadcast, unknown unicast, and multicast traffic forwarding; underlay and overlay control
plane, multitenancy support, etc.), common designs, and design considerations (Layer 3 gateway, etc.) at
the time of this writing.
FabricPath technology uses many of the best characteristics of traditional Layer 2 and Layer 3
technologies. It retains the easy-configuration, plug-and-play deployment model of a Layer 2 environment.
It also introduces a control-plane protocol called FabricPath Intermediate System to Intermediate System
(IS-IS). This Shortest-Path First (SPF) routing protocol is used to determine reachability and select the best
path or paths to any given destination FabricPath switch in the FabricPath network. The result is increased
stability and scalability, fast convergence, and the capability to use multiple parallel paths typical in a Layer
3 routed environment.
Underlay network
The FabricPath spine-and-leaf network uses Layer 2 FabricPath MAC-in-MAC frame encapsulation, and it
uses FabricPath IS-IS for the control-plane in the underlay network. Each FabricPath switch is identified by
a FabricPath switch ID. The FabricPath IS-IS control plane builds reachability information about how to
reach other FabricPath switches.
Overlay network
FabricPath has no overlay control plane for the overlay network. End-host information in the overlay
network is learned through the flood-and-learn mechanism with conversational learning.
Multicast traffic
For a FabricPath network, the FabricPath IS-IS control plane by default creates two multidestination trees
that carry broadcast traffic, unknown unicast traffic, and multicast traffic through the FabricPath network. IP
multicast traffic is by default constrained to only those FabricPath edge ports that have either an interested
multicast receiver or a multicast router attached and use Internet Group Management Protocol (IGMP)
snooping. For Layer 2 multicast traffic, traffic entering the FabricPath switch is hashed to a multidestination
tree to be forwarded. For Layer 3 IP multicast traffic, traffic needs to be forwarded by Layer 3 multicast
using Protocol-Independent Multicast (PIM). After traffic is routed to the destination VLAN, then it is
forwarded using the multidestination tree in the destination VLAN.
The placement of a Layer 3 function in a FabricPath network needs to be carefully designed. Two major
design options are available: internal and external routing at a border spine, and internal and external
routing at a border leaf. Both designs provide centralized routing: that is, the Layer 3 routing functions are
centralized on specific switches.
FabricPath technology currently supports up to four FabricPath anycast gateways. If the spine-and-leaf
network has more than four spine switches, the Layer 2 and Layer 3 boundary needs to be distributed
across the spine switches. Also, with SVIs enabled on the spine switch, the spine switch disables
conversational learning and learns the MAC address in the corresponding subnet. You need to consider
MAC address scale to avoid exceeding the scalability limits of your hardware.
Figure 6.
Internal and external routing at the border spine
Figure 7.
Internal and external routing at the border leaf
Multitenancy
The FabricPath spine-and-leaf network supports Layer 2 multitenancy with the VXLAN network (VN)-
segment feature (Figure 8). The VN-segment feature provides a new way to tag packets on the wire,
replacing the traditional IEEE 802.1Q VLAN tag. This feature uses a 24-bit increased name space.
Customer edge links (access and trunk) carry traditional VLAN tagged and untagged frames. These are the
VN-segment edge ports.
FabricPath links (switch-port mode: fabricpath) carry VN-segment tagged frames for VLANs that have
VXLAN network identifiers (VNIs) defined. These are the VN-segment core ports. To support multitenancy,
same VLANs can be reused on different FabricPath leaf switches, and IEEE 802.1Q tagged frames are
mapped to specific VN-segments. VN-segments are used to provide isolation at Layer 2 for each tenant.
The VLAN has local significance on the FabricPath leaf switch, and VN-segments have global significance
across the FabricPath network. On each FabricPath leaf switch, the network keeps the 4096 VLAN spaces,
but across the whole FabricPath network, it can support up to 16 million VN-segments, at least in theory.
The FabricPath spine-and-leaf network also supports Layer 3 multitenancy using Virtual Routing and
Forwarding lite (VRF-lite), as shown in Figure 9. The FabricPath network is a Layer 2 network, and Layer 3
SVIs are laid on top of the Layer 2 FabricPath switch. With VRF-lite, the number of VLANs supported
across the FabricPath network is 4096.
Figure 9.
Layer 3 multitenancy example with VRF-lite
Item Description
End-host reachability and distribution Flood and learn plus conversational learning
Broadcast and unknown unicast traffic Flood by FabricPath IS-IS multidestination tree
Supported hardware ● Cisco Nexus® 7000 Series Switches including the Cisco Nexus
7700 platform switches
● Cisco Nexus 5500 and 5600 platform switches
● Cisco Nexus 6000 Series Switches
The Cisco Nexus 9000 Series introduced an ingress replication feature, so the underlay network is
multicast free. The VXLAN VTEP uses a list of IP addresses of other VTEPs in the network to send
broadcast and unknown unicast traffic. These IP addresses are exchanged between VTEPs through the
static ingress replication configuration (Figure 10).
Overlay network
The VXLAN flood-and-learn spine-and-leaf network doesn’t have a control plane for the overlay network.
The Layer 2 overlay network is created on top of the Layer 3 IP underlay network by using the VTEP
tunneling mechanism to transport Layer 2 packets. The overlay network uses flood-and-learn semantics
(Figure 11).
Multicast group scaling needs to be designed carefully. Ideally, you should map one VXLAN segment to
one IP multicast group to provide optimal multicast forwarding. You can also have multiple VXLAN
segments share a single IP multicast group in the core network; however, the overloading of multicast
groups leads to suboptimal multicast forwarding.
Note that the maximum number of inter-VXLAN active-active gateways is two with a Hot-Standby Router
Protocol (HSRP) and vPC configuration. Also, the spine Layer 3 VXLAN gateway learns the host MAC
address, so you need to consider the MAC address scale to avoid exceeding the scalability limits of your
hardware.
Figure 12.
Internal and external routing on the spine layer
The maximum number of inter-VXLAN active-active gateways is two with an HSRP and vPC configuration.
Also, the border leaf Layer 3 VXLAN gateway learns the host MAC address, so you need to consider the
MAC address scale to avoid exceeding the scalability limits of your hardware.
Figure 13.
Internal and external routing on the border leaf
Multitenancy
The VXLAN flood-and-learn spine-and-leaf network supports Layer 2 multitenancy (Figure 14). VXLAN
uses a 24-bit segment ID, or VNID, which enables up to 16 million VXLAN segments to coexist in the same
administrative domain. To support multitenancy, the same VLAN can be reused on different VTEP switches,
and IEEE 802.1Q tagged frames received on VTEPs are mapped to specific VNIs. VNIs are used to provide
isolation at Layer 2 for each tenant. VLAN has local significance on the leaf VTEP switch, and the VNI has
global significance across the VXLAN network.
The VXLAN flood-and-learn spine-and-leaf network also supports Layer 3 multitenancy using VRF-lite
(Figure 15). The VXLAN flood-and-learn network is a Layer 2 overlay network, and Layer 3 SVIs are laid on
top of the Layer 2 overlay network. With VRF-lite, the number of VLANs supported across the VXLAN
flood-and-learn network is 4096.
Figure 15.
Layer 3 multitenancy example using VRF-lite
Item Description
Supported hardware ● Cisco Nexus 7000 Series Switches including the Cisco Nexus 7700 platform
switches
● Cisco Nexus 9000 Series Switches
For feature support and more information about Cisco VXLAN flood-and-learn technology, please refer to
the configuration guides, release notes, and reference documents listed at the end of this document.
With IP multicast enabled in the underlay network, each VXLAN segment, or VNID, is mapped to an IP
multicast group in the transport IP network. Each VTEP device is independently configured with this
multicast group and participates in PIM routing. The multicast distribution tree for this group is built through
the transport network based on the locations of participating VTEPs.
With the ingress replication feature, the underlay network is multicast free. The VXLAN VTEP uses a list of
IP addresses of other VTEPS in the network to send broadcast and unknown unicast traffic. These IP
addresses are exchanged between VTEPs through the BGP EVPN control plane or static configuration.
Note that the ingress-replication feature is supported only on Cisco Nexus 9000 Series Switches.
Multicast traffic
VXLAN MP-BGP EVPN supports overlay tenant Layer 2 multicast traffic using underlay IP multicast or the
ingress replication feature. Note that ingress replication is supported only on Cisco Nexus 9000 Series
Switches.
Overlay tenant Layer 3 multicast traffic is supported by two ways: (1) Layer 3 PIM-based multicast routing
on an external router for Cisco Nexus 7000 Series Switches including the Cisco Nexus 7700 platform
switches and Cisco Nexus 9000 Series Switches. (2) Tenant Routed Multicast (TRM) for Cisco Nexus 9000
Cloud Scale Series Switches. TRM is based on a standards-based next-generation control plane
(ngMVPN) described in IETF RFC 6513 and 6514. It delivers tenant Layer 3 multicast traffic in an efficient
and resilient way. Please note that TRM is only supported on newer generation of Nexus 9000 switches
such as Cloud Scale ASIC–based switches. For feature support and more information about TRM, please
refer to the configuration guides, release notes, and reference documents listed at the end of this
document.
You need to design multicast group scaling carefully, as described earlier in the section discussing Cisco
VXLAN flood-and-learn multicast traffic.
Figure 17.
Design for external routing at the border leaf
The spine switch can also be configured to send EVPN routes learned in the Layer 2 VPN EVPN address
family to the IPv4 or IPv6 unicast address family and advertise them to the external routing device. With this
design, tenant traffic needs to take only one underlay hop (VTEP to spine) to reach the external network.
However, the spine switch needs to run the BGP-EVPN control plane and IP routing and the VXLAN VTEP
function.
Figure 18.
External routing with border spine design
Multitenancy
The VXLAN MP-BGP EVPN spine-and-leaf architecture uses MP-BGP EVPN for the control plane. As an
extension to MP-BGP, MP-BGP EVPN inherits the support for multitenancy with VPN using the VRF
construct. In MP-BGP EVPN, multiple tenants can co-exist and share a common IP transport network while
having their own separate VPNs in the VXLAN overlay network (Figure 19).
In the VXLAN MP-BGP EVPN spine-and-leaf network, VNIs define the Layer 2 domains and enforce Layer
2 segmentation by not allowing Layer 2 traffic to traverse VNI boundaries. Similarly, Layer 3 segmentation
among VXLAN tenants is achieved by applying Layer 3 VRF technology and enforcing routing isolation
among tenants by using a separate Layer 3 VNI mapped to each VRF instance. Each tenant has its own
VRF routing instance. IP subnets of the VNIs for a given tenant are in the same Layer 3 VRF instance that
separates the Layer 3 routing domain from the other tenants.
Table 3 summarizes the characteristics of the VXLAN MP-BGP EVPN spine-and-leaf network.
Item Description
Broadcast and unknown unicast traffic Forwarded by underlay multicast (PIM) or ingress replication
(Note: Ingress replication is supported only on Cisco Nexus 9000 Series
Switches.)
Underlay control plane Any unicast routing protocol (static, OSPF, IS-IS, eBGP, etc.)
Layer 3 VXLAN gateway ● Distributed anycast gateway on leaf ToR switch for inter-VXLAN routing
● Border leaf switch for external routing
(Note: The spine switch only needs to run BGP-EVPN control plane and IP
routing.)
● Border spine switch for external routing
Supported hardware ● Cisco Nexus 7000 Series Switches including the Cisco Nexus 7700 platform
switches
● Cisco Nexus 9000 Series Switches
For feature support and more information about VXLAN MP-BGP EVPN, please refer to the configuration
guides, release notes, and reference documents listed at the end of this document.
Regarding routing design, the Cisco MSDC control plane uses dynamic Layer 3 protocols such as eBGP to
build the routing table that most efficiently routes a packet from a source to a spine node. Most customers
use eBGP because of its scalability and stability.
Figure 20 shows an example of a Layer 3 MSDC spine-and-leaf network with an eBGP control plane (AS =
autonomous system).
Figure 20.
Example of MSDC Layer 3 spine-and-leaf network with BGP control plane
The Layer 3 spine-and-leaf design intentionally does not support Layer 2 VLANs across ToR switches
because it is a Layer 3 fabric. Each host is associated with a host subnet and talks with other hosts through
Layer 3 routing. Host mobility and multitenancy is not supported.
Because the fabric network is so large, MSDC customers typically use software-based approaches to
introduce more automation and more modularity into the network. The automation tools can handle
different fabric topologies and form factors, creating a modular solution that can adapt to different-sized
data centers. MSDCs are highly automated to deploy configurations on the devices and discover any new
devices’ roles in the fabric, to monitor and troubleshoot the fabric, etc. Many MSDC customers write
scripts to make network changes, using Python, Puppet and Chef, and other DevOps tools and Cisco
technologies such as Power-On Auto Provisioning (POAP).
Item Description
Multitenancy No
Supported hardware ● Cisco Nexus 7000 Series Switches including the Cisco Nexus 7700 platform
switches
● Cisco Nexus 3000 Series Switches
● Classic LAN mode: manages Cisco Nexus Data Center infrastructure deployed in legacy designs,
such as vPC design, FabricPath design, etc. It provides real-time health summaries, alarms, visibility
information, etc.
● Media controller mode: manages Cisco IP Fabric network for Media solution and helps transition
from an SDI router to an IP-based infrastructure. It provides workflow automation, flow policy
management, and third-party studio equipment integration, etc. (This mode is not relevant to this
white paper.)
● Storage Area Network (SAN) controller mode: manages Cisco MDS Series switches for storage
network deployment with graphical control for all SAN administration functions. It provides rich-
insights telemetry information and other advanced analytics information, etc. (This mode is not
relevant to this white paper.)
From Cisco DCNM Release 11.2, Cisco Network Insights applications are supported; these applications
consist of monitoring utilities that can be added to the Data Center Network Manager (DCNM). Two Cisco
Network Insights applications are supported:
● Cisco Network Insights - Advisor (NIA): monitors the data center network and pinpoints issues that
can be addressed to maintain availability and reduce surprise outages. NIA constantly scans the
customer’s network and provides proactive advice with a focus on maintaining availability and
alerting customers about potential issues that can impact uptime.
● Cisco Network Insights – Resources (NIR): provides a way to gather information through data
collection to get an overview of available resources and their active processes and configurations
across the entire Data Center Network Manager (DCNM).
Conclusion
This document presented several spine-and-leaf architecture designs from Cisco, including the most
important technology components and design considerations for each architecture at the time of the
writing of this document.
The Cisco FabricPath spine-and-leaf network is proprietary to Cisco. It is simple, flexible, and stable; it has
good scalability and fast convergence characteristics; and it supports multiple parallel paths at Layer 2. But
a FabricPath network is a flood-and-learn-based Layer 2 technology. Its control plane protocol is
FabricPath IS-IS, which is designed to determine FabricPath switch ID reachability information. To learn
end-host reachability information, FabricPath switches rely on initial data-plane traffic flooding. As the
number of hosts in a broadcast domain increases, the negative effects of flooding packets become more
pronounced. The Layer 3 routing function is laid on top of the Layer 2 network. Common Layer 3 designs
use centralized routing: that is, the Layer 3 routing function is centralized on specific switches (spine
switches or border leaf switches). The FabricPath network supports up to four anycast gateways for
internal VLAN routing.
The Cisco VXLAN flood-and-learn spine-and-leaf network complies with the IETF VXLAN standards (RFC
7348). It transports Layer 2 frames over the Layer 3 IP underlay network. But it is still a flood-and-learn-
based Layer 2 technology. As the number of hosts in a broadcast domain increases, it suffers the same
flooding challenges as the FabricPath spine-and-leaf network. The Layer 3 routing function is laid on top of
the Layer 2 network. Common Layer 3 designs use centralized routing: that is, the Layer 3 routing function
is centralized on specific switches (spine switches or border leaf switches). The VXLAN flood-and-learn
spine-and-leaf network supports up to two active-active gateways with vPC for internal VXLAN routing.
● The MP-BGP EVPN protocol is based on industry standards, allowing multivendor interoperability.
● It enables control-plane learning of end-host Layer 2 and Layer 3 reachability information, enabling
organizations to build more robust and scalable VXLAN overlay networks.
● It uses the decade-old MP-BGP VPN technology to support scalable multitenant VXLAN overlay
networks.
● The EVPN address family carries both Layer 2 and Layer 3 reachability information, thus providing
integrated bridging and routing in VXLAN overlay networks.
● It reduces network flooding through protocol-based host MAC address IP address route distribution
and ARP suppression on the local VTEPs.
● It provides optimal forwarding for east-west and north-south traffic and supports workload mobility
with the distributed anycast function on each ToR switch.
● It provides VTEP peer discovery and authentication, mitigating the risk from rogue VTEPs in the
VXLAN overlay network.
● It provides mechanisms for building active-active multihoming at Layer 2.
● Its underlay and overlay management tools provide many network management capabilities,
simplifying workload visibility, optimizing troubleshooting, automating fabric component
provisioning, automating overlay tenant network provisioning, etc.
Cisco VXLAN MP-BGP EVPN spine-and-leaf architecture is one of the latest innovations from Cisco. It is
designed to simplify, optimize, and automate the modern multitenancy data center fabric environment.
Cisco spine-and-leaf layer 2 and layer 3 fabric comparison
Table 5 compares the four Cisco spine-and-leaf architectures discussed in this document: FabricPath,
VXLAN flood-and-learn, VXLAN MP-BGP EVPN, and MSDC Layer 3 networks. Please review this table and
each section of this document carefully and read the reference documents to obtain additional information
to help you choose the technology that best fits your data center environment.
Cisco Spine-and-Leaf Cisco FabricPath Cisco VXLAN Flood Cisco VXLAN MP-BGP Cisco MSDC
Layer 2 and Layer 3 and Learn EVPN Layer 3
Fabric
End-host detection Flood and learn Flood and learn Localized flood and learn None (localized IP
with ARP suppression subnet)
End-host reachability Flood and learn plus Flood and learn MP-BGP EVPN Unicast routing
and distribution conversational protocol (eBGP)
learning
Broadcast and unknown Flood by FabricPath Forwarded by underlay Forwarded by underlay PIM Stops at leaf ToR
unicast traffic IS-IS PIM or ingress or switch
multidestination tree replication
ingress replication
(Note: Ingress-
replication is (Note: Ingress replication is
supported only on supported only on Cisco
Cisco Nexus 9000 Nexus 9000 Series
Series Switches.) Switches.)
Underlay control plane FabricPath IS-IS Any unicast routing Any unicast routing protocol Unicast routing
protocol (static, OSPF, (static, OSPF, IS-IS, eBGP, protocol (eBGP)
IS-IS, eBGP, etc.) etc.)
Layer 3 gateway ● Internal and external ● Internal and external ● Distributed anycast gateway ● Leaf ToR switch
routing at border routing at spine VTEP on leaf ToR switch for inter- for internal
spine VXLAN routing routing
● Internal and external
● Internal and external routing at border leaf ● Border leaf switch for ● Border leaf
routing at border VTEP external routing switch for
leaf external routing
● Up to 2 active-active (Note: The spine switch
● Up to 4 FabricPath gateways with vPC only needs to run BGP-
anycast gateways supported
supported
EVPN control plane and IP
routing.)
● Border spine
switch for
external routing
(Note: The spine switch
needs to support VXLAN
routing on hardware.)
Standard reference TRILL-based (Cisco RFC 7348 RFC 7348 and RFC8365 Routing protocol
proprietary) (previously draft-ietf-bess-
evpn-overlay)
Supported hardware ● Cisco Nexus 7000 ● Cisco Nexus 7000 ● Cisco Nexus 7000 Series ● Cisco Nexus
Series Switches Series Switches Switches including the Cisco 7000 Series
including the Cisco including the Cisco Nexus 7700 platform Switches
Nexus 7700 Nexus 7700 platform switches including the
platform switches switches Cisco Nexus
● Cisco Nexus 9000 Series
7700 platform
● Cisco Nexus 5500 ● Cisco Nexus 9000 Switches switches
and 5600 platform Series Switches
switches ● Cisco Nexus
3000 Series
● Cisco Nexus 6000
Switches
Series Switches
● Cisco Nexus
9000 Series
Switches