Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

5-Stage Clos Architecture

5-Stage Clos Overview

5-stage Clos architecture allows for large-scale topologies. With its additional aggregation layer, you can interconnect multiple pods into a single fabric. Superspine devices provide the additional layer that interconnects multiple pods. Planes are groups of superspine devices. Each 5-stage topology consists of one or more planes. Each plane consists of one or more superspine devices. See below for an example.

Careful planning and consideration are required to build large 5-stage Clos networks. Refer to the limitations below when you're designing and validating your 5-stage topology. For assistance, contact Juniper Support.

5-Stage Clos Limitations

  • You cannot change a 3-stage topology to a 5-stage topology.
  • You must use the same overlay control protocol (static VXLAN or MP-EBGP-EVPN, specified during template creation) for all rack types in all pods.
  • Root Cause Analysis is not supported.
  • IPv6 / IPv4 support:
    • IPv6 support in the underlay depends on the NOS. See the feature matrix.
    • IPv6 applications are supported as of Apstra version 4.1.0.

    • IPv6 virtual networks are supported on EVPN blueprints as of Apstra version 4.1.1.

    • The entire fabric across all pods must be either all IPv4, all IPv6 or all dual-stack
  • Unsupported external connectivity implementations:
    • One generic system connecting to multiple pods
    • EVPN with external generic systems on superspine devices
    • External generic systems on spine devices and leaf devices in the same pod
  • Unsupported blueprint modifications:
    • Add or remove superspine planes

5-Stage Clos and EVPN

Extending EVPN networks across multiple pods within the same blueprint adds the following value:

  • Scaling: provide any-to-any connectivity for applications distributed across multiple pods.
  • Redistributing Workloads: To load-balance applications, you can migrate a group of applications from one pod to another pod while preserving application IP and MAC addresses.
  • Performing pod maintenance: Migrate all applications from one pod to another, while preserving the application IP and MAC addresses.
  • Active / Standby applications across sites / pods: Deploy A/S applications across multiple pods to provide high availability at pod level, or as part of application migration tasks.
  • Facilitate external connectivity for a virtual network from a remote pod without external connectivity.

5-stage Clos networks support the Junos QFX series of switches. You can use the ESI redundancy protocol, create templates from them, and then use those templates as pods in 5-stage Clos networks. For more information about working with Juniper devices with EVPN, see Juniper EVPN Support.

Just like in other Apstra-managed networks, required configuration is rendered to bring up multi-pod networks, and with proprietary Intent-based Networking technology the networks are validated to ensure they operate as designed.

The method for creating cross-pod virtual networks is the same method as for 3-stage networks.

Create 5-Stage Clos Network

Creating a 5-stage Clos network follows the same workflow as for 3-stage Clos networks, with the addition of creating a pod-based template and adhering to the 5-stage requirements described in the workflow below:
  1. Confirm that the global catalog includes logical devices (Design > Logical Devices) that meet the 5-stage requirements below; create them if necessary:
    • Make sure that devices have a sufficient number of ports and port groups; the exact number depends on your design.
    • Spine logical devices require a leaf-facing port group, and if they will be facing a superspine device they also require a Superspine port role in that port group.
    • Superspine logical devices require a Spine port role in the port group.
  2. Confirm that the global catalog includes interface maps (Design > Interface Maps) that map the logical devices to the correct device profiles; create them if necessary. The required number of interface maps depends on your design; each device model used requires its own interface map. At a minimum, if you are using only one model, you need two interface maps as listed below:
    • Superspine logical device to device profile
    • Spine logical device to device profile
  3. Create one or more rack-based templates, each including at least one link for Superspine Connectivity.
  4. Create a pod-based template that uses as the pod the rack-based template(s) created in the previous step. Pod-based templates are essentially templates of templates where one or more rack-based templates are combined into a larger topology. (If you don't see the rack-based template that you created in the previous step in the pods drop-down list, it's probably because you didn't include a superspine-to-spine link.)
  5. Create pools for resources (ASNs, IPv4 addresses, IPv6 addresses) needed in the network.
  6. Create a blueprint using the pod-based template that you created in the previous step.
  7. Build the 5-stage Clos network in the same manner as for building a 3-stage Clos network.

Modify 5-stage Clos Network

You can modify 5-stage blueprints in the same manner as for 3-stage networks, provided that you take into account the limitations described above. For information about rack changes, see Racks. For information about adding and removing pods, or changing pod names, see Pods, and for information about adding superspine devices to planes see Planes.Racks (Datacenter)