4.1 AOS-CX Hardware Portfolio and State Database Architecture

4.1 AOS-CX Hardware Portfolio and State Database Architecture

Modern enterprise campus networks demand continuous availability, high-bandwidth switching, automated telemetry, and programmatic management. Traditional legacy network operating systems—such as ArubaOS-S (formerly ProCurve) and conventional competitor platforms—were engineered decades ago around monolithic software architectures. In those legacy architectures, independent protocol processes communicate directly with one another through point-to-point Inter-Process Communication (IPC) messaging queues. When an individual protocol daemon (such as OSPF or Spanning Tree) encountered a fatal memory leak or software fault, the entire switch often suffered a cascading operating system crash, dropping all transit traffic and necessitating a multi-minute cold reboot.

To overcome these operational limitations, Aruba developed AOS-CX (ArubaOS-CX). Built from the ground up on a hardened, modern Linux kernel, AOS-CX replaces fragile point-to-point IPC messaging with a revolutionary database-centric microservices architecture. Understanding the internal mechanics of this state database and navigating the broader Aruba CX hardware portfolio are core competencies for campus access network engineers.

---

The AOS-CX Hardware Switch Portfolio

The Aruba CX switching family provides end-to-end coverage across all tiers of modern campus network topologies, from compact wiring closets to high-density modular aggregation and multi-terabit campus core backbones.

+-------------------------------------------------------------------------+
|                       ARUBA CX SWITCH PORTFOLIO                         |
|                                                                         |
|   CAMPUS CORE / AGGREGATION                                             |
|   +-----------------------------------------------------------------+   |
|   | CX 8325 / CX 8360: High-density 1/10/25/40/100G, EVPN-VXLAN, VSX|   |
|   | CX 8100: Compact 1U campus core/aggregation, 1/10/25/40/100G, VSX|   |
|   | CX 6400: Modular 5-slot / 10-slot chassis, redundant mgmt, VSX  |   |
|   +-----------------------------------------------------------------+   |
|                                    ^                                    |
|                                    | (Uplinks / VSX-LAG)                |
|   CAMPUS ACCESS LAYER              v                                    |
|   +-----------------------------------------------------------------+   |
|   | CX 6300: Stackable Access (up to 10-member VSF), 10/25/50G, PoE+|   |
|   | CX 6200: Enterprise Access (up to 8-member VSF), 10G SFP+, PoE+ |   |
|   | CX 6100: Entry L2 Access, 10G SFP+ uplinks, No VSF, No NAE      |   |
|   | CX 6000: Basic L2 Access, 1G SFP uplinks, No VSF, No NAE        |   |
|   +-----------------------------------------------------------------+   |
+-------------------------------------------------------------------------+

1. Aruba CX 6000 and CX 6100 Series (Entry Access)

• Deployment Tier: Cost-effective Layer 2 enterprise edge, branch offices, and small-to-medium business (SMB) wiring closets.
• CX 6000 Highlights: Fixed 1GbE copper ports (12, 24, or 48 ports) with 1GbE SFP uplinks. Up to 370W Class 4 Power over Ethernet (PoE). Fanless models for quiet office environments.
• CX 6100 Highlights: Adds high-speed 1GbE/10GbE SFP+ uplinks. Supports enterprise Layer 2 switching, static routing, and ACLs.
• Key Constraints: Neither the CX 6000 nor the CX 6100 supports Virtual Switching Framework (VSF) stacking or the Network Analytics Engine (NAE). They operate strictly as standalone switches.

2. Aruba CX 6200 Series (Enterprise Access)

• Deployment Tier: Enterprise wiring closets, branch aggregation, and campus edge deployments requiring stacking and Layer 3 routing.
• Hardware Models: CX 6200F fixed-configuration models (12, 24, and 48 ports; the 12-port models cannot stack with the 24- or 48-port models).
• Stacking Support: Supports VSF stacking up to 8 members using standard 10G SFP+ uplink ports.
• Capabilities: Layer 2 switching plus Layer 3 static routing and OSPF in current AOS-CX releases, ACLs, PoE+ models (budgets vary by SKU), and Network Analytics Engine (NAE) support.

3. Aruba CX 6300 Series (High-Performance Stackable Access & Aggregation)

• Deployment Tier: High-density enterprise campus access, Wi-Fi 6/6E wireless aggregation, and compact distribution.
• Hardware Models: CX 6300F and CX 6300M with modular power supplies, redundant fans, and Smart Rate multi-gigabit copper ports (1GbE, 2.5GbE, 5GbE).
• Stacking Support: Supports VSF stacking up to 10 members with high-bandwidth 10G, 25G, and 50G SFP56 stacking interconnects.
• Capabilities: Full dynamic Layer 3 routing (OSPF, BGP, VRF-lite, PIM multicast), 60W Class 6 PoE, and full NAE telemetry support backed by dedicated internal flash storage.

4. Aruba CX 6400 Series (High-Density Modular Campus Chassis)

• Deployment Tier: Campus access, aggregation, and core environments requiring carrier-class modular hardware redundancy.
• Chassis Options: 5-slot (CX 6405) and 10-slot (CX 6410) chassis supporting hot-swappable line cards, dual redundant management modules, and fabric modules delivering up to 28 Tbps switching capacity.
• High Availability: Uses Virtual Switching Extension (VSX) rather than VSF to pair chassis with dual independent control planes. Line cards span 1GbE, 10GbE, 25GbE, 40GbE, and 100GbE.

5. Aruba CX 8100, CX 8325, and CX 8360 Series (Aggregation and Core)

• CX 8100 Series: Compact 1U fixed form factor campus aggregation and core switch providing flexible 1/10/25/40/100GbE connectivity and VSX pairing.
• CX 8325 and CX 8360 Series: High-performance, ultra-low-latency cut-through switches designed for large campus cores, aggregation hubs, and Top-of-Rack (ToR) data center environments. Feature dense 10G/25G and 40G/100G interfaces, advanced Layer 3 routing, EVPN-VXLAN network overlays, and VSX active-active gateway capabilities.

---

Hardware Portfolio Comparison Matrix

---

The AOS-CX State Database Architecture

The defining architectural distinction of AOS-CX is its centralized state database, implemented via the Open vSwitch Database (OVSDB) schema, paired with a high-resolution Time-Series Database (TSDB).

+-------------------------------------------------------------------------+
|                 AOS-CX STATE DATABASE ARCHITECTURE                      |
|                                                                         |
|   USER / MANAGEMENT INTERFACES                                          |
|   +---------------+  +---------------+  +---------------+  +--------+   |
|   | CLI Console   |  | Web GUI       |  | REST API      |  | Central|   |
|   +-------+-------+  +-------+-------+  +-------+-------+  +----+---+   |
|           |                  |                  |               |       |
|           +------------------+--------+---------+---------------+       |
|                                       | (REST / Internal Schema API)    |
|                                       v                                 |
|   +=================================================================+   |
|   |                  CENTRALIZED STATE DATABASE                     |   |
|   |  - OVSDB: Single Source of Truth for Config & Operational State |   |
|   |  - TSDB: Time-Series Historical Telemetry & Event Metrics       |   |
|   +=================================================================+   |
|               ^             ^             ^             ^               |
|       Pub/Sub |     Pub/Sub |     Pub/Sub |     Pub/Sub |               |
|               v             v             v             v               |
|   +---------------+ +---------------+ +---------------+ +-----------+   |
|   | Port Daemon   | | LACP Daemon   | | STP Daemon    | | OSPF Dmn  |   |
|   +-------+-------+ +-------+-------+ +-------+-------+ +-----+-----+   |
|           |                 |                 |               |         |
|           +-----------------+--------+--------+---------------+         |
|                                      v                                  |
|   +=================================================================+   |
|   |           HARDWARE ASICs (ASIC Drivers & Forwarding Tables)     |   |
|   +=================================================================+   |
+-------------------------------------------------------------------------+

1. Database as the Single Source of Truth

In AOS-CX, the state database is the single, authoritative repository for every configuration setting, operational state metric, and hardware counter:

• Configuration State: VLAN memberships, IP addressing, OSPF area parameters, and ACLs reside as structured rows within the database.
• Operational State: Port link status, negotiated LACP neighbor states, transceiver optical levels, and learned MAC addresses are continuously recorded in the database.
• Decoupled Daemons: Software daemons (microservices) such as portd, lacpd, mstpd, and ospfd hold no private internal state. They do not maintain point-to-point connections with other daemons.

2. The Publish/Subscribe (Pub/Sub) Model

Communication across AOS-CX processes operates strictly through a publish/subscribe mechanism:

1. When an event occurs—such as a network engineer plugging a fiber patch cable into interface 1/1/1—the physical port manager (portd) detects optical carrier signal.
2. Rather than broadcasting messages to STP, LACP, and LLDP, portd simply writes an update to the Interface table in OVSDB, setting link_state = up.
3. Daemons interested in interface states subscribe to updates on that specific database table. OVSDB immediately notifies lacpd, mstpd, and lldpd of the change.
4. Each subscribing daemon evaluates the database event, performs its algorithmic calculation, and writes its resulting operational state back to the database.
5. The hardware abstraction layer reads the updated state from the database and programs the physical Application-Specific Integrated Circuit (ASIC) forwarding tables.

3. Self-Healing Resilience and Process Restartability

Because microservices maintain no private volatile memory state, AOS-CX delivers unmatched software fault tolerance:

• Process Restart: If a software bug causes the OSPF daemon to crash or terminate unexpectedly, the Linux system manager immediately respawns the ospfd microservice.
• Instant State Recovery: Upon initialization, the new ospfd instance does not need to rebuild its state from scratch or request state dumps from neighboring daemons. It instantly reads its entire operational topology and neighbor state directly from OVSDB.
• Zero Forwarding Disruption: During the sub-second daemon restart window, the switch hardware ASICs continue forwarding transit data packets at line rate using the existing forwarding tables stored in hardware memory. The network experiences zero packet drops or topology flaps.

---

100% REST API Programmability and Transactional Integrity

In legacy operating systems, external automation scripts relied on "screen-scraping" CLI output over Telnet or SSH, parsing fragile text blocks using regular expressions. In AOS-CX, the CLI is not a monolithic control entity; it is simply a modular client application interacting with the state database.

• Unified Data Model: Every command entered in the CLI translates directly into an internal REST transaction against the database schema.
• Native REST API: AOS-CX exposes its configuration and operational state through a RESTful API (URIs such as https://<switch-ip>/rest/v10.xx/system) using JSON over HTTPS, and the built-in AOS-CX REST API Reference (a Swagger UI) documents the available resources.
• Transactional Integrity: Configuration changes are validated and written to the database as transactions, so a request that fails validation is rejected rather than half-applied. For multi-step changes, AOS-CX checkpoints let you roll the whole configuration back to a known state (covered in the Operate chapter).