There are several universal architectures in the Arista design portfolio. The Enterprise Universal Cloud Network can be used in the data center and in the Cognitive Campus, and the Enterprise Anycloud Network expands beyond the data center. All of these designs deliver the Arista Unified AnyCloud Architecture offering unified orchestration, management and telemetry with CloudVision. Arista's guiding principles are Universal(Common architectures from small to huge), Simple(a single operating system for all platforms and hardware), Open(standards-based features and functions), Programable(Easy to use APIs and automation), and Visible(Full state Telemetry and flow information) The key to these guiding design principles is the use of the Arista EOS architecture for its hardware and software-based devices. EOS is based on a Linux kernel, standard and fully open. EOS uses agent processes, that use a Publish/Subscribe model to populate the NetDB on each device which contains all device states. NetDB can then be used by Aristas CloudVision products to offer full-state telemetry and flow information for the entire Universal Architecture. Because Arista is using a single binary for all hardware and software-based devices Arista can implement hardware abstraction. Unlike some other manufacturers, Arista uses the latest Merchant Silicon and when coupled with the standard open EOS kernel allows very fast development cycles, fewer bugs, and faster adoption by customers since it is the same EOS.

VMware NSX Datacenter(NSX-T) platform allows the creation of secure virtual networks on top of your current physical network and virtual server infrastructure. SDN abstracts the underlying infrastructure of your network and programs separate virtual networks using the software. Using the NSX-T manager to create the NSX infrastructure, we prepare the Compute and Edge hosts participating in NSX. The compute hosts connect to the DC fabric, typically a CLOS or Spine/Leaf architecture. The Edge is connected to the DC fabric and external switches to provide public and private routing to WAN and Internet. Using the software, NSX can recreate entire physical networks, from the layer two switching, complex BGP routing, and FWs load balancers VPNs. This is possible by creating layer 3 Virtual Tunnel Endpoints (VTEPs) that use the Geneve encapsulation protocol to create an overlay in the compute and Edge cluster hosts. This overlay can then build layers two and three segments to connect our Virtual NSX routing and switch infrastructure. This Geneve Encapsulated Overlay also allows us to create a Physical to Virtual (P/V) point where we can either encapsulate the virtual networks and send them across the layer three underlays or decapsulate to connect to devices outside NSX.

The Cisco ACI: Tenant & Fabric Connectivity learning path is the second part of our ACI fundamentals training, following the "Cisco ACI Fabric Initialization and Hypervisor Connectivity" path. This path covers two key areas: 1) Fabric Infrastructure configurations, which involve physical fabric setup, including vPCs, VLANs, loop prevention, underlay BGP protocol, etc. 2) Tenant Configurations, defining logical constructs like application profiles, bridge domains, and EPGs. In this Learning Path, students will learn to create Tenants, Application Profiles, Bridge domains, and EPGs, by using objects for connectivity within a physical ACI fabric. They will also discover how to connect Layers 2 and 3 to external networks and explore methods for segmentation using contracts and filters to support both Inter-EPG and Intra-EPG segmentation.

Cisco ACI is a policy-driven CLOS or Spine/Leaf based switching fabric utilizing layer 3 ECMP routing in the underlay and VXLAN encapsulation in the overlay to transport layer two and layer three traffic East/West across the fabric and North/South in and out of the fabric. ACI consists of the Application Policy Infrastructure Controller (APIC), a centralized controller that manages all aspects of the ACI fabric. The leaf switches are ToR switches that provide connectivity between servers and external networks, and the spine switches are Layer 3 switches that provide ECMP high-bandwidth connectivity between leaf switches. An ACI fabric can be expanded East/West by adding leafs, cabling to the spines, and registering them. ACI was designed to operate as "One Big Switch" (like a chassis-based NEXUS 7K) with the controllers acting like the Supervisors, the spines as fabric modules, and leafs acting as blades. This approach allows us to decouple these elements from the chassis and place them anywhere in the data center. The leafs (blades) can be placed anywhere in the data center, so you are not limited to a chassis. We can take this decoupling one step further and put a leaf in a remote data center (remote leaf), place a spine and leaf fabric extension into a second data center (multi-pod), or a new spine-leaf fabric in a data center (multi-site). Using the NEXUS Dashboard Orchestrator (NDO), we can treat multiple fabrics as one entity from a policy standpoint and manage and perform day two operations from a single pane of glass. The power of ACI allows us to stretch layer two and layer three across multiple fabrics and use a single policy for forwarding traffic in the data center. This Learning Module will guide you through basics and implementation skills.