Aruba CX 10000 Advanced cheat sheet

The CX 10000 is a 1U top-of-rack switch built on a Broadcom Trident3-class switching ASIC paired with an AMD Pensando Elba DPU for inline distributed services.

Two DPU-attached ports per switch carry all stateful service traffic; the DPU sits inline in the data path rather than as a bump-in-the-wire sidecar.

Front-panel density is 48 ports of 10/25G SFP plus 6 ports of 40/100G QSFP for uplinks and fabric, with the DPU consuming internal ports rather than front-panel ports.

The DPU provides stateful services including firewall, NAT, encryption/IPsec, and flow-based telemetry, programmed through a policy API rather than through the switch CLI.

The switch ASIC handles L2/L3 forwarding at line rate; traffic requiring stateful services is steered to the DPU by policy, and non-steered flows bypass it.

Dual power supplies and redundant fans are field-replaceable; the DPU is an embedded subsystem, so DPU failure is handled by switch-level HA rather than by hot-swapping.

The platform is positioned for data-center leaf/TOR roles where east-west security enforcement at the first hop is required without adding appliance hops.

AOS-CX on CX 10000 shares the same CLI, REST API, and VSX/EVPN feature set as other CX 8xxx/9xxx switches, with DPU features layered on top.

AOS-CX uses a candidate configuration model: changes take effect on commit; 'checkpoint' and 'rollback' provide saved configuration snapshots.

Configuration is stored in the startup configuration; 'write memory' or 'copy running-config startup-config' persists the running configuration.

The CLI is organized into a hierarchical context tree (config, interface, router, vlan); 'exit' moves up one level and 'end' returns to the privileged prompt.

REST API and the Central/NETCONN-API interfaces expose the same object model as the CLI; every CLI object has a corresponding URI.

User roles are defined with 'aaa authorization' and local/remote RBAC; the 'admin' role is superuser and auditor roles are read-only.

Firmware is managed with dual-bank images; 'boot system' selects the active image and 'copy' commands stage a new image for upgrade.

VSF (Virtual Switching Framework) stacks CX 10000-class switches into one logical device using front-panel or dedicated stacking links.

'show running-config', 'show startup-config', and 'show configuration diff' are the primary tools for verifying configuration state.

VLANs are created in config context; an interface becomes a trunk with 'vlan trunk allowed' or an access port with 'vlan access'.

SVIs are configured with 'interface vlan N' and 'ip address'; routing between VLANs requires 'ip routing' enabled globally.

OSPF, BGP, and static routes are supported; BGP is the standard underlay/overlay protocol for EVPN fabrics on this platform.

MLAG-equivalent on AOS-CX is VSX: two switches share a logical L2 domain over an ISL and a keepalive link, with a single active-forwarding peer.

VSX requires matching VSX system MAC, a dedicated ISL (typically 40/100G), and a keepalive path; split-brain is prevented by the keepalive.

ARP and ND suppression are enabled per-VLAN and are required for efficient EVPN-VXLAN distributed routing.

Link aggregation uses LACP ('lacp mode active') and supports multi-chassis LAG under VSX for dual-homed servers.

Loop prevention uses STP/RSTP/MSTP by default; in EVPN fabrics, STP is typically disabled on fabric-facing ports.

The DPU enforces stateful firewall policy per flow; the first packet of a flow is evaluated against policy and subsequent packets hit the flow table.

Policies are defined as distributed firewall rules with match on source/destination, L4 ports, and optionally application/URL categories.

NAT (source and destination) is performed on the DPU; return traffic is statefully reversed without explicit reverse rules.

IPsec and MACsec encryption are DPU-offloaded; encryption does not consume switch ASIC resources.

Policy is applied at the first-hop switch, so east-west traffic between VMs/containers is inspected without tromboning to a central firewall.

Flow telemetry (IPFIX-style) is exported from the DPU, giving per-flow visibility including allow/deny decisions and byte counts.

Policy objects are managed centrally (e.g., through Pensando Policy and Services Manager or Aruba Fabric Composer) and pushed to all DPUs.

Steering to the DPU is done with policy-based redirection; traffic not matching a service policy is forwarded normally by the ASIC.

EVPN uses BGP route types: Type 2 (MAC/IP), Type 3 (inclusive multicast), Type 5 (IP prefix), and Type 4 (Ethernet segment) for multihoming.

VXLAN VNIs map to VLANs via 'vxlan vni' under the VLAN context; the VTEP source is a loopback reachable over the underlay.

The underlay is typically eBGP or OSPF providing loopback reachability; the overlay is iBGP EVPN between VTEPs.

Distributed anycast gateway uses the same IP and MAC on every leaf, allowing optimal routing without tromboning to a spine.

Type 5 routes enable symmetric IRB, where routing happens at the ingress leaf and the packet is VXLAN-encapsulated to the egress leaf.

Multihoming uses EVPN Ethernet segments (Type 4) with all-active forwarding; VSX can provide the Ethernet segment on CX switches.

ARP/ND suppression reduces flooding by answering ARP locally from the EVPN MAC/IP table.

CX 10000 integrates into an EVPN fabric as a leaf/VTEP, with DPU services applied to VXLAN-encapsulated or decapsulated flows.

Micro-segmentation enforces policy per workload identity rather than per subnet; identity is derived from group tags or endpoint attributes.

Role-based segmentation uses user-role or group tags assigned at the port or via 802.1X, matched in policy rules.

Default-deny is the baseline: an explicit permit is required for allowed flows; implicit deny drops unmatched traffic.

Policy is stateful, so only the initiating direction needs a rule; return traffic is permitted by the flow table.

Segmentation can be enforced at L2 (VLAN/group isolation), L3 (VRF/ACL), or L4-7 (DPU stateful policy); CX 10000 enables the L4-7 tier at the leaf.

VRFs provide tenant isolation at L3; leaking routes between VRFs requires explicit route-target import/export.

Policy changes are applied atomically to the DPU flow tables; in-flight flows may be re-evaluated depending on policy versioning.

Audit and compliance reporting draws on DPU flow logs, which record the rule that permitted or denied each flow.

AOS-CX supports streaming telemetry via gNMI and REST, pushing counters and state at configurable intervals rather than polling.

IPFIX/NetFlow export from the DPU provides per-flow records with 5-tuple, bytes, packets, and policy action.

sFlow is supported on switch interfaces for sampled packet-level visibility.

'show interface', 'show vlan', and 'show ip route' provide on-box verification; 'show tech' bundles diagnostics for support.

Aruba Central and Fabric Composer aggregate telemetry across the fabric and provide dashboards and alerting.

SNMP traps and syslog are supported for legacy integration; syslog severity and facility are configurable per destination.

Event logs and audit logs are separate: audit logs record configuration changes with user identity.

Analytics on DPU flow data enables anomaly detection, top-talkers, and policy-hit analysis without dedicated probes.

VSX provides device-level HA with sub-second failover; the ISL carries peer traffic and the keepalive detects peer failure.

VSX active-gateway allows both peers to forward for the same anycast gateway IP/MAC, avoiding a standby path.

DPU failure: traffic steered to a failed DPU is handled by policy fail-open or fail-closed behavior, configurable per policy.

'show vsx status', 'show vsx config-consistency', and 'show lacp' are first-line VSX troubleshooting commands.

Common EVPN issues: VNI/VLAN mismatch, missing Type 2 routes, underlay loopback unreachable, and MTU too small for VXLAN overhead (50 bytes).

VXLAN MTU: underlay must carry 1600+ bytes to accommodate 50 bytes of encapsulation plus inner frame.

Firmware upgrades use dual-bank images; 'show boot' confirms the active bank and 'boot system' changes it.

Support files are collected with 'show tech' and DPU diagnostics are gathered separately through the DPU management interface.