Search for an Aruba CX simulator and the results split in two: HPE community threads explaining that the official AOS-CX Switch Simulator exists and is free, and forum posts from people trying to get it running in EVE-NG or GNS3. Both halves are true, and neither answers the practical question — which of the four realistic ways to run an AOS-CX lab fits the job in front of you.
This post compares them: the official simulator on a desktop hypervisor, the EVE-NG route, the GNS3 route, and the cloud route — including the image-format steps each one actually requires, because that's where most first attempts stall.
Quick comparison
| Route | Where it runs | Image handling | Multi-node topologies | Setup effort | Cost | Best for |
|---|---|---|---|---|---|---|
| Official simulator (OVA) | VirtualBox / VMware on your machine | Import OVA as-is | ⚠️ Manual per-VM wiring | ✅ Minutes for one switch | Free (HPE account) | First contact with AOS-CX CLI |
| EVE-NG | Your server / bare metal | Extract VMDK, convert to QCOW2 | ✅ Drag-and-drop, mixed vendors | ❌ Host build + image prep | Free image; host is yours | Home study, offline topologies |
| GNS3 | Your machine or GNS3 VM (KVM) | Extract VMDK, official appliance | ✅ Drag-and-drop, mixed vendors | ⚠️ Appliance import | Free image; host is yours | Home study on a single PC |
| NetPilot (cloud) | Browser — NetPilot cloud (Enterprise: dedicated/on-prem) | Built in for you (enterprise custom image) | ✅ AI agent builds from a prompt | ✅ Prompt to running lab ~2 min | Signature & Enterprise plans | Team migration rehearsal + validated configs |
Bottom line: the official AOS-CX Switch Simulator is free, HPE-supported, and runs the real NOS — for solo study, EVE-NG or GNS3 plus the free image is genuinely hard to beat. The cloud route earns its place when the lab is a team deliverable: on NetPilot's Signature and Enterprise plans the simulator is built in for you as a custom vendor image, and an AI agent designs the topology, deploys it in ~2 minutes, and runs validation checks — the model that makes sense when "run an Aruba lab" really means "prove a migration before the window opens."
The official AOS-CX Switch Simulator: free, real, and hungry
Start with the concession that shapes this whole comparison: HPE did this right. The AOS-CX Switch Simulator — the official Aruba switch simulator — is the real AOS-CX network operating system packaged as a virtual machine — not a lookalike quiz environment. OSPF and BGP converge, MSTP elects roots, VSX pairs sync state, and the REST API and Network Analytics Engine answer — the same control plane that runs on 6300s and 8325s.
It's distributed at no charge through the HPE Networking Support Portal — a free account is required (the portal is the successor to the Aruba Support Portal, so older guides saying "ASP account" mean the same thing). The download is an OVA that imports directly into VirtualBox, VMware Workstation, Fusion, or ESXi. There's no license key, no time bomb, and no hardware-ownership check.
The honest part is the resource math. Each simulator instance wants about 4 GB of RAM and 2 CPU cores. One switch on a laptop is trivial. The topologies that answer real questions are not one switch:
- 2-switch VSX pair: 8 GB RAM, 4 vCPUs
- Campus core + access (4 nodes): 16 GB RAM, 8 vCPUs
- Migration mirror, both estates (8 nodes): 32 GB RAM, 16 vCPUs — plus whatever the old-vendor images need
Those are node totals alone — the host OS and the EVE-NG/GNS3 layer want their own few gigabytes on top, so size the host above the sum, not at it. That's why almost nobody stops at the bare hypervisor: importing OVAs one by one and hand-wiring virtual NICs gets old at node three. The desktop-hypervisor route is the right first hour with the CLI; for topologies, you graduate to one of the next three options.
Running the AOS-CX simulator in EVE-NG
EVE-NG is the workhorse answer for a self-hosted multi-vendor lab, and AOS-CX is a first-class citizen — with one image-format step that trips everyone the first time: EVE-NG doesn't take the OVA as-is. The OVA is a container; inside it is a VMDK disk that has to come out and become a QCOW2. Per the official EVE-NG how-to:
# 1. Unpack the download, then the OVA itself (an OVA is a tar archive)
unzip ArubaOS-CX_*_ova.zip
tar -xvf ArubaOS-CX_*.ova # yields arubaoscx-disk-image-...vmdk
# 2. Convert VMDK -> QCOW2 on the EVE-NG host
/opt/qemu/bin/qemu-img convert -f vmdk -O qcow2 arubaoscx-disk-image-*.vmdk virtioa.qcow2
# 3. Move it into a folder that MUST start with "arubacx-"
mkdir -p /opt/unetlab/addons/qemu/arubacx-10.15
mv virtioa.qcow2 /opt/unetlab/addons/qemu/arubacx-10.15/
# 4. Fix permissions
/opt/unetlab/wrappers/unl_wrapper -a fixpermissionsThe folder-name prefix (arubacx-, lower case) is load-bearing — EVE-NG maps folders to node templates by name, and a mistyped prefix is the classic "my image doesn't appear in the node list" cause. Give each node the template defaults of 2 vCPUs and 4096 MB, boot it, and log in as admin with an empty password.
What you get for the effort is real: drag-and-drop topologies, AOS-CX next to whatever else your migration involves on the same canvas, snapshots, and full offline operation. What you own is also real: the EVE-NG host itself, its RAM ceiling, image upgrades (each new AOS-CX release repeats the convert-and-copy dance), and the fact that sharing the lab with a colleague means sharing a server.
Running the AOS-CX simulator in GNS3
GNS3 covers the same self-hosted ground with a slightly friendlier on-ramp: there's an official ArubaOS-CX Simulation Software appliance in the GNS3 marketplace, maintained in the public GNS3 registry.
The image-format reality is one step simpler than EVE-NG here — a point most guides miss: the GNS3 appliance consumes the extracted VMDK directly. No QCOW2 conversion. You still extract the disk from the OVA yourself — the appliance can't fetch it for you; the registry entry points you back to the support portal — then import the appliance template and hand it the arubaoscx-disk-image-...vmdk file when prompted.
The template's defaults, straight from the registry definition: 4096 MB RAM and 2 vCPUs per node, 8 network adapters, telnet console, and KVM required — which in practice means running nodes on a Linux host or inside the GNS3 VM rather than natively on Windows/macOS. The registry keeps version entries current with simulator releases, so a freshly downloaded image typically matches an existing template entry.
Between the two self-hosted routes there's no wrong answer: GNS3 is the gentler install on a single PC you already own; EVE-NG scales better into a dedicated lab server and mixed-vendor estates. Both run the identical NOS image, both work fully offline, and both leave the host, the RAM, and the image lifecycle on your plate.
Is there an Aruba CX simulator online?
The direct answer first: HPE does not host the AOS-CX simulator as a web service. There's no browser sandbox on the support portal, and hosted copies aren't something a third party can hand out — the download sits behind each user's own portal login. "Aruba CX simulator online" — a search plenty of people run — has no free-hosted answer.
What exists instead is the cloud lab route, and it's honest to say up front who it's for: teams, not solo study. NetPilot is built on ContainerLab, and its vendor lineup comes in three layers — Nokia SR Linux, FRR, and Linux are built in on every plan; Cisco IOL, Juniper cRPD, Arista cEOS, Palo Alto, and Fortinet come in via self-serve bring-your-own-image (BYOI); and Aruba AOS-CX sits in the custom vendor tier: on the Signature and Enterprise plans, any ContainerLab-compatible image — the AOS-CX simulator you download from HPE included — is built in for you. Signature runs on NetPilot's cloud with the founder building the first labs alongside you; Enterprise adds a dedicated environment, on-prem included. NetPilot never distributes vendor images; the simulator comes from your own HPE account, once, and after that the agent deploys it like any other node.
The difference from the self-hosted routes isn't access to the image — it's what happens after the image exists:
"Build an Aruba migration lab: two AOS-CX cores as a VSX pair with active-gateway on VLANs 10/20/30, two access switches on LAGs, MSTP with VLANs 10/20 in instance 1 and 30 in instance 2. Then run a failover battery on the VSX pair under continuous ping and report seconds of loss."
The agent designs the topology, generates the per-switch configs, deploys the lab in about 2 minutes, and runs the checks — no EVE-NG host to build, no QCOW2 conversion, no RAM ceiling on your laptop, and the lab lives in the cloud rather than on someone's desk (on the Enterprise plan, lab artifacts are shared across the team). Direct CLI is always available too: every node is the real AOS-CX NOS with SSH access, so show spanning-tree and show lacp interfaces by hand work exactly as they do on the self-hosted routes.
If the reason you searched for a simulator is a Cisco or Comware estate headed to Aruba, the Cisco to Aruba migration walkthrough covers the translation table and the validation battery that runs inside this kind of lab.
Which Aruba CX lab option should you choose?
- First hours with the AOS-CX CLI → the plain OVA in VirtualBox or VMware. Free, running in minutes, and one switch is all you need to learn
vlan accessandno shutdownhabits. - Home study and offline topologies → EVE-NG or GNS3. This is their home turf and the honest recommendation: the image is free, the tools are mature, and a 16 GB machine comfortably runs two or three nodes — a four-node campus wants 24 GB or more once the host OS and the lab platform take their share. Pick GNS3 for the friendlier single-PC install, EVE-NG for a dedicated lab server.
- Certification-style self-paced learning on a budget → same answer: self-hosted. A cloud platform buys you nothing here that your own RAM doesn't.
- Team migration rehearsal, validated configs, evidence for a change board → NetPilot on the Signature or Enterprise plan. When the lab's output is a routing diff, measured failover times, and a config set someone signs off on — and more than one engineer needs to touch it — the agent-run cloud model is what those plans exist for, with Enterprise adding a dedicated environment and team-shared lab artifacts. (The maintenance window itself is a separate rehearsal — the network cutover rehearsal walkthrough covers step ordering, timed convergence, and rollback.)
The four routes run the same NOS. The choice is really about who provisions the compute, who does the image plumbing, and whether the lab is a personal study tool or a team deliverable.
FAQ
Where do I download the Aruba AOS-CX simulator?
The AOS-CX Switch Simulator is distributed through the HPE Networking Support Portal — sign in, search the software downloads for the AOS-CX Switch Simulator, and download the OVA package. A free portal account is required. HPE does not offer the simulator as a hosted web service; you download the image and run it in a hypervisor, in EVE-NG or GNS3, or have it built into a cloud lab platform under your own account.
Is the Aruba CX simulator free?
Yes. HPE distributes the AOS-CX Switch Simulator at no charge — the only requirement is a free HPE Networking Support Portal account. What isn't free is the compute under it: each simulator instance needs about 4 GB of RAM and 2 CPU cores, so an eight-switch topology wants roughly 32 GB of RAM on the host, plus an EVE-NG, GNS3, or hypervisor setup you maintain yourself.
Do I need an ASP account to download the AOS-CX simulator?
Yes — an account on the HPE Networking Support Portal (the successor to the Aruba Support Portal, ASP) is required to reach the download. Registration is free and not gated on owning Aruba hardware or holding a support contract. The login-gated download is also why reputable guides never link the image file directly: each user sources the simulator under their own account.
What are the limitations of the AOS-CX simulator compared to real hardware?
The simulator runs the real AOS-CX control plane — OSPF, BGP, MSTP, VSX, the REST API, and the Network Analytics Engine all behave like the real NOS — but forwarding is software, not switch silicon. That means no ASIC-dependent behavior: QoS queuing under congestion, hardware rate limiting, and TCAM capacity limits won't reproduce. There are no optics, transceiver, or cabling behaviors to test, no PoE, no physical VSF stacking, and throughput numbers are meaningless. It validates configuration and protocol behavior, not performance.
Run the lab that answers your question
If you're here to learn AOS-CX, download the simulator from HPE and stand it up in GNS3 or EVE-NG this afternoon — it's free, it's the real NOS, and this post's conversion steps are the only friction between you and a running switch.
If you're here because a migration is coming and the lab needs to produce evidence a team can act on, describe the target design at app.netpilot.io — on the Signature and Enterprise plans the AOS-CX image is built in for you and the agent takes it from prompt to validated topology.
Copy-paste ready: the vendor-migration rehearsal prompt builds a parallel-run migration lab with equivalence checks — paste it into app.netpilot.io and swap the target vendor for your AOS-CX image.
Related: Cisco to Aruba migration: translation table + lab validation · Network migration lab