This blog is the second in part in a series recapping Apstra’s experience presenting at Networking Field Day 19.
I kicked off the technical presentations with a couple of whiteboards (big surprise). While Apstra has presented at NFD before, I firmly believe if we make assumptions about basic knowledge we have the potential to lose half the audience for the rest of the show if we don’t start with the basics.
First, I presented a whiteboard overview of our primary Apstra AOS (Apstra Operating System) reference architecture.
First and foremost Apstra is a software company. Apstra Intent-Based Data Center Automation provides multi-vendor data center automation and analytics. Apstra Intent-Based Data Center Automation supports leaf-spine data center designs and is extensible to support other environments.
Apstra Intent-Based Data Center Automation is implemented via AOS Server operating as a virtual machine instance. AOS does not take over control of the control plane or the data plane – it is simply in the orchestration/management plane (or the newly-minted “validation plane” as the delegates referred to it). AOS is the single source of truth where all intent is defined and validated in real-time against the operational state of the managed network.
At its core, AOS is a distributed system. An AOS agent is deployed to each switch (or locally on the AOS server if desired) to configure, monitor, and validate the intent locally, while reporting back to AOS Server centrally.
Apstra AOS is agnostic to switch hardware vendor and switch operating system vendor. We test and validate extensively in both our own labs and in our customers labs to ensure compatibility with various combinations of hardware, software, and AOS. We remove the burden of configuring lengthy EVPN, BGP, VRF, MLAG, VXLAN, VLAN, etc. , regardless of vendor. Just as powerful is our Day 2 analytics, where we have built in probes to continuously validate in real-time that your intent is being met and we enable our customers to roll their own probes to decide what’s important for them to monitor in their own data center. Rags presented a great demo session on Intent-Based Analytics later in our NFD19 show.
My second whiteboard was the big reveal, prompting a Vanna White-channeling hand wave. This whiteboard breaks down the building blocks used to design a data center in AOS Server. While you can create these all by hand completely customized, Apstra provides many of these reusable building blocks out of the box based on typical switch configurations. I’ll show you the 10,000 foot view first, and then I’ll drill down into each section.
Now I know this looks like a lot, but when you’re building out a data center in AOS this process can be completed from start to finish in about six minutes, as shown in the hilarious video DJ kicks off his presentation with.
The left-hand side of the whiteboard shows the initial building blocks used to provide an abstracted view of intent. These are how you describe in vendor-neutral speak what your requirements are for your devices. The first building block is a Logical Device.
A Logical Device is an abstracted description of requirements for a device – the device intent. A device could be a leaf switch, a spine switch, or a server. The device depicted in the diagram is for a leaf switch. In the Logical Device for a leaf I might say I require 8x25G. For this set of ports I specify one or more roles. A role tells AOS what type of device is intended to plug in to that port. In this example I specify either servers or peer-links (in the case of MLAG or vPC) are allows to be connected to the 8x25G ports. Next, I say I require 4x100G interfaces on this leaf, which can be used to connect to spines or external routers. At this point I have captured the intent for a leaf switch in my data center. I could also model spines and servers, or use the pre-defined templates provided by Apstra. All of these building blocks are reusable.
The next building block is a Rack Type.
A Rack Type is used to build out intent for a rack, including leafs and servers. Again, you will not see vendor-specifics yet, as a Rack Type is also an abstracted view of intent. A Rack Type pieces together a leaf Logical Device and server Logical Device building blocks into a bigger building block. In a rack type you also specify whether the servers are Layer 2 or Layer 3 (Routing on Host, in which an agent is deployed to the server), how many uplinks per server there are, how many switches at the top of rack should be present, and the number of links to the spines.
Now that I’ve defined Logical Devices for leafs, spines, and servers, and built out racks, I combine them together into a Template. The green arrows in the following diagram depict how the building blocks are used to construct a Template.
When creating a Template I pick the spine Logical Device, and choose which Rack Types to add, and how many of each. I am allowed to mix and match Rack Types in a single Template. Let’s look a little deeper about what other pieces of intent I define in a Template.
A Template is where (and if) I add external routers. While these are not managed directly by AOS, we do configure things like the BGP neighbor relationship on the leaf or spine side of the house for the appropriate peering and route advertisement.
There are several other nerd knobs you can tweak in a Template:
- Routing Policy: Whether to advertise all routes, or a default route.
- Overlay Control: Whether to use static VXLAN, or EVPN.
- IPv4 or IPv6
- External Links: Where the external router is connected (to leafs or spines).
I like to think of a Template as a rubber stamp. It carves out and illustrates intent for a potential data center. It is reusable – I can stamp out many data centers using the same Template. I can also have many rubber stamps in my collection for different data center designs. The rubber stamp in and of itself is not a data center though. It is an abstraction. In order to make a data center that I’m able to attach physical devices to, I need to make a print from that rubber stamp. The print is what we call a Blueprint, and it is a living and breathing data center.
You can also think of a Blueprint as an instantiation of a Template. However once you instantiate a Blueprint it becomes its own living, breathing entity, having taken on a life of its own. It is now a separate, independent object from the Template. If I were to go make changes to an existing Template I had used to stamp out a Blueprint, the print wouldn’t reflect those changes. This is by design so that live data centers are not impacted by changes in the building blocks.
Before we look at the pink features of a Blueprint, let’s walk through how physical devices actually get added into a Blueprint. At this point of the design process we will want to select which vendor(s) we are going to use for our data center.
There are two objects that bind the logical abstractions to the physical devices in AOS Server, which are called the Device Profile and the Interface Map.
Starting on the bottom of the diagram, the Device Profile is what represents an instance of a physical device. For example, a Dell Z9100-ON leaf switch. The Device Profiles ship out of the box for all devices AOS supports, but you can model your own if there is a configuration we have not yet modeled. The Device Profile captures the hardware and software capabilities of the switch, e.g. number of ports, supported switch operating system, and lists possible port transformations, e.g. which ports provide choice of which speeds, use of breakout cables, etc. Again, you shouldn’t need to create these, you will simply choose one out of the box, and map it to the next object, the Interface Map.
The Interface Map is the glue that binds the physical, vendor-specific Device Profile to the abstracted Logical Device from the very first step. In the Interface Map you specify how the ports are going to be used to meet your intent. For example, I would map those 8x25G ports from the initial Device Profile to ports that have those capabilities on the Dell Z9100-ON. I would do the same for the 4x100G ports by selecting ports that meet those requirements on the physical device.
The Interface Maps are created with all the other building blocks (under the Resource tab), but are actually used inside the Blueprint as the glue. All you have to do is click a leaf or a spine in a Blueprint, and select an eligible Interface Map. Last, you are prompted to select an available device (based on the serial number) from the list of AOS Managed Devices. AOS Managed Devices are resources AOS has discovered and deployed agents to. Selecting a specific Managed Device tells AOS which switch to use from your inventory, and where in the topology it should go.
Now that you have added physical devices to a Blueprint you must provide pools of identities for AOS to use when it renders configuration.
Resource pools include identities like BGP Autonomous System Numbers (ASNs), IP address pools for interfaces and VTEP IPs, and VXLAN Network Identifier pools (VNIs). AOS will draw from these pools when it renders underlay and overlay configuration on the topology. External routers are also housed under resources. If you added an external router abstraction (intent) to the blueprint, you point to a specific external router to be used by the blueprint from the available resources.
To wrap up a Blueprint, let’s take a look at what we’ll be managing from a Day 2 perspective once I’ve built out my data center. These features are listed in pink in Blueprint bubble in the previous diagram:
- Virtual Networks: Add rack-local (VLANs) or inter-rack (VXLANs) virtual networks to a blueprint.
- Security Zones: Provide Layer 3 isolation between tenants by leveraging VRFs.
- vSphere Inventory (NEW!): View VMware vCenter objects within AOS. After adding a vCenter and associating it to a Blueprint you’ll be able to see the following:
- VM inventory per vCenter
- VM inventory per Hypervisor
- Port group inventory
- Port group:VLAN ID association
- VM:port group association
- VMware port group : VLAN ID :: AOS virtual network : VLAN ID association
- Add Intent-Based Analytics probes to correlate AOS and vCenter virtual networking
- Intent-Based Analytics: Add or create your own powerful probes to monitor and alert based on what matters to you, using a custom big data analytics pipeline. Remember to check out Rags’ NFD19 presentation to see Intent-Based Analytics in action!
And that’s all folks! Again, that may seem like a lot, but it only takes minutes to put the building blocks together to get a living, breathing data center. Thanks for taking the time to read, and please leave any and all questions below in the comments section.
Check back soon for our next NFD19 blog post, featuring a summary of Rags’ Intent-Based Analytics presentation.