Apstra Operating System
AOS™ is the first and only vendor-agnostic, closed-loop intent-based network (IBN) operating system. It enables autonomous lifecycle operations that reduce network services delivery time, outages and cost by 50-90%.
With release 2.0, AOS allows enterprises and service providers to design, implement and operate modern L3 fabric while supporting L2 applications using VXLAN. AOS 2.0 enables networking teams to design, implement and operate underlay and overlay as a single integrated system. AOS 2.0 provides automation, clear visibility across underlay and overlay and problem resolution capabilities.
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 2.0 provides turnkey, vendor-agnostic, autonomous lifecycle operations of VXLAN, spanning design, implementation, operations and validation — for any virtual, container-based, and bare-metal workloads.
For example, the networking team can automate the configurations and verifications of VXLAN on an IP fabric, without using a SDN controller, or EVPN. Without AOS, there are many manual VXLAN management steps you will have to perform. With AOS, these manual steps are completely automated.
To learn more about AOS, download our Data Sheet here.
To learn more, download this VXLAN Feature Brief here.
“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.”
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.
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.
- I need to stream all my telemetry to my time series database and visualize it in grafana.
- I need to query all paths between server 1 and server 2, which have utilization above 50%.
- 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 and Simplicity
Reduce risk and increase profit by enabling a data center architecture that provides for scale, mobility, security, and simplicity of operations.
Provide Operational Control and Visibility
Learn how AOS 2.0 delivers rack-based design intent, real-time closed-loop telemetry, VXLAN support for integrated overlay and underlay and much more.
AOS 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.
Intent-Based Analytics: What is it?
by Sasha Ratkovic
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.
- 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
- Intra-rack (VLAN), or inter-rack (VXLAN) *
- Extensible services (intent, resources, expectations)**
Arista EOS and vEOS
Juniper Junos **
Cumulus Linux and CVX
AOS ETC (Extensibility Tools for the Community)
3rd Party Tool Integration
3rd Party Big-Data Platform Integration
Legacy Devices Integration
Routing table verification
Host name, transceiver, interface, LAG / MLAG
MAC & ARP
Server and devices health
Intent-based anomaly detection
Telemetry streaming via protocol buffers
Extensible telemetry collection **
Device lifecycle management
Tested capacity: 1600 devices
Interactive network visualization
Extensible device agents
AOS backup / restore
Graph model and GraphQL API **
Blueprint modifications with staging and commit is fully supported
Addition and deletion of virtual networks and endpoints
Role-Based Access Control (RBAC)
* New features in AOS 2.0
** Technology Preview
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 network services delivery time, outages and cost by 50-90%.
Who uses 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-rendered configurations to your chosen vendor hardware options, and let AOS continuously 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?
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 L3 scale-out fabric with VXLAN overlay providing inter-rack L2 segments, 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).
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 VXLAN or VLAN, 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.
CIOs also want to move to modern L3 leaf / spine fabric for agility and scale, but are being held back by legacy L2 applications. AOS allows the networking team to design, build, deploy and validate underlay and overlay (VXLAN) as a single integrated autonomous system, without being locked into a vendor hardware platform and massive do-it-yourself programming.
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. Furthermore, you can’t mix-and-max different vendor’s switch hardware platforms for different spine or leaf switch configurations. 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.