Apstra Operating System

Apstra Operating System

Apstra Operating System™ (AOS) delivers the first and only intent-based networking system (IBNS) for command and control automation of your network services. AOS enables the only vendor-agnostic Self-Operating Network™ that configures itself, fixes itself, and defends itself.

How it Works

Apstra Operating System (AOS) automates the entire lifecycle of network infrastructure and services.  Starting with customer-declared statements of intent, AOS automates the various processes involved in designing and deploying network configurations, and ensuring that the network is always “ready for business” through real-time telemetry and analytics that provide continuous validation.

Scroll to See How it Works

Design

Your template is generated for the design.
  • “I need to connect 1000 virtual machines in the most cost effective way.”

  • “I need to connect these 50 end points using a virtual network.”

  • “I need to connect 9 compute racks and 1 storage rack in a non-blocking way.”

“I need to connect 1000 virtual machines in the most cost‑effective way.”

“I need to connect these 50 end points using a virtual network.”

"I need to connect 9 compute racks and 1 storage rack in a non-blocking way."

lines-1 Created with Sketch.
line-down-1 Created with Sketch.

Operate

Apstra generates a blueprint that includes all required configurations.
  • Build: I need to pull my IP addresses from my IPAM system, using open networking for compute, deep buffers for storage, and specify rules for cabling.

  • Change: I need to add a rack to my POD, and those 200 virtual machines to this application.

  • Change: I need to change the cabling to the storage rack.

Build

"I need to pull my IP addresses from my IPAM system, using open networking for compute, deep buffers for storage, and specify rules for cabling."

Change 1

"I need to add a rack to my POD, and those 200 virtual machines to this application."

Change 2

"I need to change the cabling to the storage rack."

lines-2 Created with Sketch.
line-down-2 Created with Sketch.

Commit

deploy-bottom Created with Sketch.
line-down-3 Created with Sketch.

Deploy

After building my infrastructure and cabling it according to my blueprint I need to:

  • Ensure infrastructure matches intent in blueprint.

  • Deploy blueprint onto infrastructure.

  • Continuously track deployment, flagging deviations from intent.

After building my infrastructure and cabling it according to my blueprint, I need to:

1

Ensure infrastructure matches intent in blueprint

2

Deploy blueprint onto infrastructure

3

Continuously track deployment, flagging deviations from intent
deploy-arrows Created with Sketch.

Validate

small-quote-symbol-white I need visibility, alerting, and controls to ensure the infrastructure is operating as intended. overall
  • mall-quote-symbol-white I need to stream all my telemetry to my time series database and visualize it in grafana.
  • quote I need to query all paths between server 1 and server 2, which have utilization above 50%.
  • quote I need to add a new telemetry parameter on the fly to help me with troubleshooting.

The Result: Take Control Of Your Network

Deliver Infrastructure Agility

Deliver Infrastructure Agility and Simplicity

Reduce risk and increase profit by enabling a data center architecture that provides for scale, mobility, security, and simplicity of operations.





Attend Webinar




Elimnate Infrastructure Downtimev

Provide Operational Control and Visibility

Learn how AOS version 1.1 delivers rack-based design intent, real-time server-based telemetry, interactive topology visualization and much more.





View Webinar




Enable Infrastructure Operational Scalability

Enable Choice of Hardware

See how a combination of open network devices and traditional vendor equipment can coexist through our central software solution.





Watch Video




Technical Resources

Apstra Operating System Technical Resources

AOS is the first product that integrates configuration and state for automating all aspects of Day 0, Day 1, and Day 2+ data center operations as well as continuous validation of business readiness.

Aeon-ZTPS Documentation

The Aeon-ZTPS is a Universal Zero-Touch- Provisioning (ZTP) Server that helps network engineers bootstrap data center network devices, giving network engineers the peace of mind that their device bootstrapping process will be fast, reliable, and universal for any vendor’s devices.

Data Sheet:

Aeon-ZTP Server

Documentation:

Latest on ReadtheDocs

AOS 1.2 Features

Services

Fabric connectivity

  • Server and rack-based design intent
  • BGP L3 CLOS fabric
  • L3 (routing on the host) server attachment
  • L2 server attachment with MLAG/LAG
  • DHCP relay

Virtual Networks
Extensible services (intent, resources and expectations)*

Device OS

Cisco NX-OS
Arista EOS and vEOS
Juniper Junos*^
Cumulus Linux and CVX
SnapRoute FlexSwitch*^
Ubuntu Servers

AOS ETC (Extensibility Tools for the Community)

Zero Touch Provisioning (ZTP) Server
Demo Tools
Template Catalog
3rd Party Tool Integration
3rd Party Big-Data Platform Integration
Legacy Devices Integration

Telemetry

LLDP, BGP, Config deviation
Interface counters
Routing table verification
Intent-based anomaly detection
Telemetry Streaming via Google protocol buffers
LAG/MLAG
MAC & ARP
Servers and devices health (cpu, mem, disk)
Extensible telemetry collection*

Platform

Single User Authentication, HTTPS*
Device Lifecycle Management
Resource Management
RESTful APIs
Headless Operation
System configlets
Interactive topology visualization
Extensible device agents*
AOS backup/restore – upgrade/rollbacks*
Graph model and GraphQL API*
Blueprint modifications w/ staging and commit*

Maintenance workflows

Scaleout Maintenance
Replacement Maintenance
Decommission Maintenance
Addition and deletion of virtual networks

* New features in Apstra Operating System™ (AOS) version 1.2
^ Experimental

AOS FAQs

What is Apstra Operating System (AOS)?

Apstra Operating System (AOS) is a Distributed Operating System for the data center network. You can deploy AOS across a network infrastructure that comprises a wide variety of name-brand or white-box network hardware, decoupling your network service design and operations from the lower-level, error-prone, manual workflows required by vendor-specific networking hardware. It reduces time and risk in all aspects of network design and operations.

Who will use AOS?

Anyone who wants to massively reduce the amount of effort involved in designing, building, deploying and operating a data center network. You can declare vendor-agnostic service intent at the network service level, deploy AOS-auto-generated configurations to your chosen vendor hardware options, and let AOS continuously auto-validate the network state against your intent. The results are massively improved service agility and reliability.

What are the benefits of using AOS?

Improved service agility: Enables networking team to rapidly design, build, deploy and validate network services
Reduced risks: Greatly reduces human error, loss of visibility, configuration drifts, and big data telemetry dumps — fundamental sources of outages and application performance issues
Reduced costs: Reduces CapEx due to vendor hardware lock-in and OpEx spent on inefficient manual operations

How does AOS accomplish this?

Design
AOS gives you an interface (Web GUI or RESTful API) to declare your network service intent, i.e. desired outcome (service) at the network level, using human language — not prescribing vendor-specific device-level jargon. A vendor-agnostic intent example: Build a L2 leaf-spine network, rack-based, for 100 servers, with 1:1 oversubscription.

Operate
Build: AOS presents you the choice of reference design templates that can meet your intent. AOS then allocates resources to your chosen template, resulting in a blueprint. Finally, AOS uses the artifacts in the blueprint to fabricate the network service configurations and telemetry expectations.

Deploy: With the push of a button, AOS deploys desired configurations (configuring resources according to the reference design).

Validate: AOS auto-validates your service expectations, executes test cases, and generates alerts and telemetry.

When you make changes dynamically — either to the physical infrastructure (add a rack, replace a switch) — or virtual network (add a virtual network, delete virtual network, add end-point to virtual network), AOS implements these in an intent-driven, closed-loop manner.

When the user changes the intent, AOS implements the change and validates that the change was indeed implemented as intended.

Why should CIOs care about AOS?

Many CIOs want to build private clouds rapidly without Amazon-like investment in people, process and technologies in order to achieve network service agility, and without being locked into a specific hardware platform.

What alternatives exist in the market?

While there are technologies that can address aspects of what AOS can deliver, there is no comparable offering available. There are home-grown tools that attempt to automate specific use cases, separate configurations and state, and require a lot of integration work that doesn’t scale operationally.

There are also server infrastructure tools on the market that do not integrate configuration and telemetry in a continuous validation loop and that do not start with business-level intent.

What are AOS’ key differentiating attributes?

Intent-driven: Network engineers interface with AOS by specifying their desired service outcome, without prescribing imperative, device-level commands to achieve the desired outcome.

Closed-loop: Network engineers’ intent, network configurations, and actual state (telemetry) are continuously validated by AOS in a closed-loop.

Vendor-agnostic: AOS allows you to completely decouple your services and operational model from vendor specificity. You can express your intent once, and then render and re-render detailed configurations for any vendor of your choice — without having to modify your intent.

What does intent mean in the context of AOS?

Intent is a network engineer’s declarative specification of desired outcome (service), describing the need for cooperative behavior of the network system infrastructure, without prescribing imperative commands to achieve it (the desired outcome). An intent example:

“Provide connectivity to 1000 servers, using L2 and/or L3 access at the edge, with oversubscription in the core of 1:1 (no oversubscription), with endpoints such as hosts, VMs or containers grouped into isolation domains (including both traffic and address space isolation). Have some endpoints reachable via the rest of the world and some not, with policies associated with isolation domains governing both security and load balancing, with connectivity to the rest of the world via at least n links to support the external traffic and protect from possible failures.”

What is closed-loop telemetry?

AOS uses a device telemetry agent to collect statuses, leveraging native protocols supported by devices and compares them against expectations, generating an anomaly if there is a mismatch. With agents running on the devices, collected data can be processed as close to the source as possible. This results in less big data telemetry, and more knowledge-enriched information across the network.

Is vendor-agnostic the same as multi-vendor?

No, they are not the same. Many networking tools support multiple hardware vendors, but typically require network engineers to create, maintain and debug a set of commands, scripts, playbooks, or programs that work only for a specific vendor. These playbooks or programs do not work for other vendor hardware platforms. You will have to write an equivalent set of programs for other vendors. Further, you can’t have mix-and-match vendor A leaf switch with vendor B spine switch. In fact you can’t even mix-and-match the same vendor switches if they have different OS versions or hardware models.

Vendor-agnostic allows you to completely decouple your services and operational model from vendor specificity. You can express your intent once, and then render and re-render detailed configurations for any vendor of your choice — without modifying your intent. You can render configurations for vendor A leaf switch interoperating with vendor B spine switch. You can swap out vendor A switch with an equivalent vendor B switch — all without changing your intent.

You can certainly change your intent — which can be done with a few mouse clicks — and have AOS auto-render new configurations for any vendor of your choice.