The Apstra Operating System

Enterprises continue to struggle with the network as the bottleneck in data center operations.

The Apstra Operating System (AOS) is a vendor-agnostic distributed operating system for the data center network that enables business agility, dramatically scales operational efficiency, and reduces downtime.

How it Works

The 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.

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.

AOS 1.1.1 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

Device OS

Arista EOS and vEOS
Cisco NX-OS
Cumulus Linux and CVX
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
Streaming via Google protocol buffers
LAG/MLAG
MAC & ARP
Servers and devices health (cpu, mem, disk)

Platform

Single User Authentication
Device Lifecycle Management
Resource Management
RESTful APIs
Headless Operation
Scalability up to 1600 devices
System configlets
Interactive topology visualization

Maintenance workflows

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

“Apstra has developed the best automation platform for building and operating networks…To put it plainly: it works. It’s easy to install and use, provides great network visibility, works on equipment from many vendors, and improves security. We use AOS at Awnix, and we’re incorporating it into the designs for our Engineered Systems for OpenStack with SDN.”

Rick Kundiger, Awnix CEO   

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.

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).

Operate with continuous validations: 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.