Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


About This In Focus Use Case


Use Case

Use the Apstra Fabric Conductor to design, build, and deploy your data center fabric.


Data center network administrator

Knowledge Level

General familiarity with data center network architectures and underlay and overlay routing.


  • Use intent-based networking and intent-based analytics to manage your fabric throughout its lifecycle.

  • Increase efficiency and network awareness by managing your data center as a whole rather than as a collection of independent devices.

  • Reduce the risk of error and misconfiguration through automation.

Products Used

  • AOS Release

  • QFX Series switches running Junos OS

    • tested on QFX10002 running Junos OS 20.2R2-S1.3 as a spine device

    • tested on QFX5110 running Junos OS 20.2R2-S1.3 as a leaf device

For the full list of supported devices and OS versions, see Supported Juniper Devices.


Are you interested in getting hands-on experience with the topics and operations covered in this guide? Visit Juniper Networks Virtual Labs and reserve your free sandbox today! You’ll find the Apstra Fabric Conductor lab by scrolling down to the Switching category.

This use case demonstrates how you can use the Apstra Fabric Conductor to design, build, and deploy a data center network. The Apstra Fabric Conductor is an intent-based networking and assurance solution that provides full lifecycle management of your data center network, including:

  • the initial design, build, and deployment of the fabric including the overlay networks

  • the ongoing management of changes (intended or unplanned network events) throughout the fabric’s lifecycle

  • the ongoing validation of your intent against the actual deployment throughout the fabric’s lifecycle

Central to the Apstra Fabric Conductor is the Apstra Operating System (AOS), the horizontally-scalable, microservices-based software that brings intent-based networking to standard off-the-shelf servers. With AOS, you design and deploy your data center network fabric and overlay networks using a declarative methodology that captures your intent. AOS then translates this intent into commands that the fabric devices understand.

In this use case, you’ll use AOS to design a simple 3-stage Clos network, build a network blueprint, and deploy that blueprint by pushing configuration to the fabric devices. AOS checks your work every step of the way, first in pre-deployment to verify the soundness of your design, and then in post-deployment to verify that the deployment matches your design intent.

Figure 1 shows the network fabric you’ll design, build, and deploy. The fabric consists of two QFX10002 switches acting as spine devices and two QFX5110 switches acting as leaf devices. Each leaf device is housed in a rack that also contains two servers running CentOS. The spine-to-leaf links are all 40 Gbps and the leaf-to-server links are all 10 Gbps. AOS manages the fabric devices over the out-of-band management network.

Figure 1: DC1 Data Center Fabric
DC1 Data Center Fabric

Once you set up the fabric, you’ll use AOS to create the overlay networks. Figure 2 shows the overlay networks you’ll create in this use case. DC1-Green and DC1-Red represent security zones or segmented networks, which are implemented as VRFs on the QFX5110 switches. DC1-Green contains routes for two virtual networks (subnets and DC1-Red contains routes for one virtual network (subnet Traffic cannot pass between the security zones as these represent different tenants (or segmented networks) that share the same fabric. Attached to the overlay networks are the bare metal server endpoints (BMS1 through BMS4). These are the CentOS servers from Figure 1. You use AOS to configure the fabric down to the fabric edge, but you configure the actual servers themselves outside of AOS.

Figure 2: DC1-Green and DC1-Red Overlay Networks
DC1-Green and DC1-Red
Overlay Networks

One important feature of AOS is its ability to separate the site-specifc details from the generic parts of a network design. To help you better understand this separation, we add a DC1 prefix to the name of any resource or construct that is typically site-specific.

General Workflow

The general workflow takes you through three distinct stages: design, build, and deploy.

  1. In the design stage, you specify the physical requirements for your fabric such as the types and roles of the fabric devices (for example, spines, leafs, superspines, external routers, servers, etc.), the speeds and feeds of the fabric devices, how the devices are organized in racks, and how the racks are connected together. The output of this stage is one or more templates that you can use as building blocks for your data center. Each template represents a standalone part of the fabric infrastructure. It can represent a row of racks, a pod, or any other construct including an entire data center.

    The design stage is device-agnostic and site-agnostic. A typical use case is for you to create a template that represents a unique row or pod in your data center. You then take this single template to create blueprints for all similar rows or pods in all your data center sites.

  2. The build stage consists of two main tasks: realizing your physical design and creating your overlay networks.

    • You realize your physical design by assigning site-specific resource pools and devices to your template.

    • You create your overlay networks by creating your security zones and then adding virtual networks (subnets) to those security zones. A security zone translates to a VRF on the QFX Series switch.

    The output of this stage is a blueprint that captures your intent for the underlay and overlay networks for a specific site.

  3. In the deploy stage, AOS translates your blueprint into configuration commands that the devices understand and pushes those commands to the devices in your fabric. AOS then verifies the deployment against the blueprint to detect cabling errors and misbehaving devices. In effect, the blueprint acts as a reference design that AOS uses to constantly measure the behavior and performance of the actual network against. Any deviations from the reference design are raised as anomalies.


To keep this use case short, we only cover the configuration of mainline parameters. Use the default settings provided in the UI for parameters that are not covered in this document.