Apstra Operating SystemTM
Data Sheet
Networking Should Be This Easy
Apstra Operating SystemTM
Apstra Operating System (AOS) gives network engineers the peace of mind that your network infrastructure operates as you intend. By deploying AOS above the network infrastructure, you can decouple your network service design and operations from the hardware-level, error-prone, and manual workflows.
(AOSTM)
What’s AOS AOS is a distributed operating system for the data center network. You can deploy AOS above your data center network infrastructure, decoupling your network service design and operations from the lower-level, error-prone, and manual workflows.
You simply specify what services the network should deliver at the network level, deploy AOS-auto-generated configurations to a wide variety of name-brand and white-box devices of your choice, and then let AOS continuously auto-validate the network state against your intent in a closed-loop. The results are significantly improved service agility, reliability, and economics.
Benefits: Improved service agility in designing, building, deploying and operating network services ● Massively reduced risks otherwise caused by human errors, loss of visibility, configuration drifts, and difficulty in analyzing telemetry dump ● Reduced CapEx due to vendor hardware lock-in and OpEx spent on inefficient manual operations
●
Key Attributes: ●
Intent-driven: Achieve your desired service outcome w/o prescribing imperative commands box-by-box
●
Closed-loop: Continuously validated intent, configurations and state
●
Vendor-agnostic: Completely decoupled services and operational model from vendor specificity
“Intent describes "what," not "how" and serves as the "universal language" for configuration. Intent is invariant, is portable, and is composable. Intent is scalable and brings context.”
Figure 1: AOS: Intent-Driven, Closed-Loop, Vendor-Agnostic AOS allows you to specify your intent, then let AOS implement this intent, and validate in closed loop - including change operations - that your intent was indeed implemented as specified. It allows you to: ●
Specify your desired outcomes (intent) at the network service level, not prescribing commands box-by-box
●
Build configuration details and cabling maps with a few mouse clicks
●
Deploy configurations with auto-executed test cases, ensuring the correct configurations have taken effect
Gartner, Emerging Technology Analysis: Intent-Based Network Design and Operation, Joe Skorupa, Andrew Lerner, Published: 8 November 2016 ID: G00316415
●
Continuously validate the “correctness” of network configurations
●
Perform change operations in an intent-driven way
Apstra Incorporated – www.apstra.com - Copyright 2017 All Rights Reserved
Data Sheet
Unlike other approaches, AOS offers: Intent - driven operations AOS allows you to declare your intents at the service level, and avoid having to prescribe vendor-specific configurations at the device level. A vendor-agnostic intent example: Build me a L2 spine-leaf network, rack-based, for 100 servers, with 1:1 oversubscription. With AOS, your service expectations, network configurations and telemetry - at both the service level and individual device level are derived from a single source of truth – your design intent. AOS provides a distributed state repository to store and correlate your data – intent, configurations and telemetry – in the form of blueprints, effectively giving you a computer-aided design, deployment, and operational experience.
Closed - loop validations AOS uses device telemetry agents to collect statuses leveraging native protocols supported by devices and compares them against expectations, generating an anomaly if there is a mismatch. With device agents running on the devices, collected data can be processed as close to the source as possible – reducing the amount of telemetry dumped from devices, and improving response time if corrective actions need to be applied to the device.
Vendor- agnostic lifecycle management and change operations AOS decouples your daily tasks in design, fabrication, deployment and continuous validations from vendor-specific hardware. You can use vendor A spine switches with vendor B leaf switches. You can swap out vendor A switch with an equivalent vendor B switch, without changing your service intent. AOS re-renders the configurations, and telemetry expectations for you.
How Do You Use AOS? Design - using vendor-agnostic reference design templates: You use AOS UI (Web GUI or RESTful API) to specify your intent - desired outcome - without prescribing imperative, vendor-specific commands to achieve the outcome. With a few mouse clicks or via RESTful API, you can rapidly formulate a reference design template, containing logical devices that are vendor-agnostic. See the example below: Your intent could be “connecting 100 servers via 10G-leaf at 1:1 oversubscription”.
Figure 2: Specify Your Network Service Intent: Vendor Agnostic Apstra Incorporated – www.apstra.com - Copyright 2017 All Rights Reserved
Data Sheet
Build: Based on your intent, AOS allocates resources to the reference design template, resulting in a blueprint. AOS uses the artifacts in the blueprint to fabricate the network service configurations and telemetry expectations.
Figure 3: Fabricate Your Network From Top to Bottom
Deploy: With your approval, AOS deploys desired configurations (configuring resources according to reference design), with auto-executed test cases.
Apstra Incorporated – www.apstra.com - Copyright 2017 All Rights Reserved
Data Sheet
Figure 4: Deploy Auto-generated, Vendor-specific Configuration Details
. Operate with Continuous Validations: AOS auto-validates expectations, and generates alerts and telemetry
Figure 5: Continuously Validate Your Intent During Operations
Automatically implement and validate change operations: AOS doesn’t stop here. When you make changes dynamically - either to the physical infrastructure (add a rack, replace a switch) - or virtual network (add a virtual network, delete a virtual network, add an 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. Apstra Incorporated – www.apstra.com - Copyright 2017 All Rights Reserved
Data Sheet
About Apstra Apstra is redefining the way networks are designed, built and operated to deliver operational agility, reliability, and operational efficiency without vendor lock-in. Apstra solves two critical problems today: the management of scalable distributed state, and providing the abstraction required to automatically translate user intent into a continuously validated infrastructure that delivers on this intent. The Apstra Operating System (AOS) is a distributed operating system for the data center network that is vendor-agnostic, intent-driven, and closed loop.
For more information, visit www.apstra.com or follow @ApstraInc
Features and Specifications 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
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)
Device OS: ● Cumulus Linux and CVX ● Arista EOS and vEOS ● Cisco NX-OS ● Ubuntu servers
Platform: ● Single User Authentication ● Device Lifecycle Management ● Resource Management
● ● ● ● ● ●
RESTful APIs Headless Operation Scalable to the largest data centers Tested for 1,600 devices System config lets Interactive topology visualization
Engage with Apstra on Twitter Follow Apstra on LinkedIn Like Apstra on Facebook
Apstra Incorporated – www.apstra.com - Copyright 2017 All Rights Reserved
AOS Extensibility Tool For the Community (AOS ETC): ● Zero Touch Provisioning (ZTP) Server ● Demo Tools ● Template Catalog ● 3rd Party Tool Integration ● 3rd Party Big-Data Platform Integration ● Legacy Devices Integration
Maintenance workflows: ● Scale-out Maintenance ● Replacement Maintenance ● Decommission Maintenance ● Addition and deletion of virtual networks