Aruba CX 10000 Advanced common mistakes
Aruba CX 10000 Advanced · Understand the traps and how to avoid them.
Treating the CX 10000 as a conventional ToR switch and assuming all policy enforcement happens in the AOS-CX control plane rather than on the DPU data plane.
Candidates study standard CX switching and skim the AMD Pensando DPU architecture, so they miss the split between the AOS-CX CPU (management, routing protocols, configuration) and the DPU (stateful services, policy enforcement, telemetry offload).
What to do instead
Build a mental block diagram: AOS-CX control plane on the switch CPU, DPU as a companion data-plane engine with its own programmable pipeline, and the internal link/API between them. For every feature, ask 'which plane executes this?' before answering.
Configuring a change and applying it immediately without using checkpoint/rollback or the candidate configuration workflow.
Candidates come from platforms where changes are live by default and do not internalize AOS-CX checkpoint/restore and the difference between running and startup config.
What to do instead
Practice the full lifecycle: create a checkpoint, make changes, verify, then use 'checkpoint auto' or manual rollback and 'copy running-config startup-config' to persist. Know which commands are disruptive and require confirmation.
Assuming a VLAN or SVI is reachable as soon as it is created, without verifying interface membership, STP state, or that the SVI is up.
Candidates memorize VLAN creation commands but forget that an SVI stays down until a member port is up and forwarding, and that STP or a shut port silently blocks traffic.
What to do instead
Adopt a verification checklist per L2/L3 change: 'show vlan', 'show interface brief', 'show spanning-tree', 'show ip interface brief', and 'show ip route'. Confirm port state and SVI state before troubleshooting higher layers.
Confusing stateless ACLs with the DPU's stateful firewall and expecting return traffic to be permitted automatically by an ACL.
Candidates apply classic ACL logic (both directions must be explicitly permitted) to a stateful policy engine, or the reverse, assuming an ACL tracks sessions.
What to do instead
Separate the concepts: ACLs are stateless and direction-specific; the DPU stateful firewall maintains flow state and permits return traffic for established sessions. Read each question for the word stateful or the presence of a session table.
Building an EVPN-VXLAN design where the underlay, overlay, and anycast gateway are mixed up, e.g., placing VTEP loopbacks in the same subnet as the underlay or forgetting the distributed anycast gateway MAC.
Candidates learn EVPN concepts in isolation and do not practice the full configuration chain: underlay IGP/BGP, VTEP loopback reachability, BGP EVPN address family, VNI-to-VLAN mapping, and distributed anycast gateway.
What to do instead
Practice a reference fabric end to end and be able to state the role of each piece: underlay provides VTEP reachability, overlay carries tenant MAC/IP routes, anycast gateway gives consistent first-hop. Verify with 'show bgp evpn', 'show interface vxlan', and 'show evpn mac-ip'.
Writing a segmentation policy that names source and destination but omits direction, scope (intra-VRF vs inter-VRF), or the enforcement point, then being surprised when traffic is or is not filtered.
Candidates focus on the match criteria and forget that policy behavior depends on where it is applied and in which direction, especially with distributed enforcement on the DPU.
What to do instead
For every policy question, explicitly identify: who enforces it (DPU vs switch), on which interface or VRF, in which direction, and whether the flow is east-west or north-south. State these aloud before choosing an answer.
Assuming telemetry is on by default or that flow data appears without configuring exporters, collectors, or the DPU analytics pipeline.
Candidates read about telemetry features but never trace the data path from DPU flow tables to the collector, so they cannot identify why a dashboard is empty.
What to do instead
Map the pipeline: DPU flow inspection, export configuration, collector reachability, and dashboard query. Practice verifying each hop, and know the distinction between streaming telemetry, sFlow/IPFIX-style flow export, and local analytics.
Diagnosing a fabric problem by starting at the overlay (EVPN routes, VXLAN tunnels) instead of confirming underlay reachability first.
Overlay symptoms look dramatic and candidates jump to BGP EVPN debugging, missing a simple underlay MTU, routing, or loopback reachability failure that breaks everything above it.
What to do instead
Use bottom-up troubleshooting: physical/link state, underlay routing to VTEP loopbacks, MTU (VXLAN encapsulation overhead), then BGP EVPN peering, then MAC/IP learning. Only move up a layer after the lower one is verified.
Treating VSX/HA as automatic and not knowing which failure (ISL vs keepalive vs both) produces which split-brain or dual-primary behavior.
Candidates memorize that VSX provides redundancy but do not reason about the roles of the inter-switch link and the keepalive path when each fails independently.
What to do instead
Draw the three failure scenarios (ISL down, keepalive down, both down) and what each member does. Practice the verification commands for VSX status, ISL, and keepalive, and know the expected safe behavior in each case.
Answering DPU service questions as if the DPU is a separate appliance with its own independent configuration, rather than an integrated component managed through AOS-CX.
Candidates conflate the Pensando DPU's programmable pipeline with an external firewall appliance and invent management workflows that do not match the integrated model.
What to do instead
Study how the DPU is commissioned, paired, and managed from AOS-CX, including how policies and services are pushed to it and how its health is monitored. Be clear on what is configured on the switch versus what runs on the DPU.