Cisco to Aruba (AOS-CX) Migration: Translation Table + Lab Validation

Ask an AI assistant how to migrate a Cisco campus to Aruba AOS-CX and you'll get the same recipe every time: download the AOS-CX simulator, stand up EVE-NG, build a feature-mapping spreadsheet, translate configs by hand or with a converter, and hope the staging gear catches what the spreadsheet missed. Every step is real work, and the recipe still has a hole in the middle: nothing in it proves the translated network behaves like the old one before the maintenance window opens.

A Cisco to Aruba migration has two halves. The first is translation — IOS switchport syntax to AOS-CX vlan syntax, port-channels to LAGs, HSRP to VRRP or VSX active-gateway. The second is proof: the translated configs converge, the STP root lands where it should, and the gateway fails over inside the SLA. Translation is a table lookup. Proof needs a lab.

This post gives you both — the full IOS-to-AOS-CX translation table (plus the Comware and ProCurve variants HPE shops actually run), then the mirror-lab walkthrough that validates the result.

The Cisco IOS to Aruba AOS-CX translation table

AOS-CX kept enough IOS muscle memory that engineers get productive fast — configure terminal, show ip route, and show vlan all carry over. The differences cluster around interface L2 configuration, aggregation, and high availability:

Sources worth keeping open during the project: HPE's CLI Reference Guide for ArubaOS-CX, ArubaOS-Switch, Comware, and Cisco IOS maps the full command set across all four OSes side by side, and the AOS-CX VSX guide covers the HA design in depth.

Bottom line: the syntax translation is the mechanical 20% of a Cisco to Aruba migration — a table lookup or a converter run. The risk lives in behavior: where the STP root lands, whether LACP negotiates, how long the gateway takes to fail over. That's lab work, and NetPilot turns it into a prompt — the agent deploys your current Cisco estate and the translated AOS-CX target side by side on real network OS images in ~2 minutes, then runs the diff-and-failover battery against both.

The gotchas the table doesn't show

Four behavioral differences bite migrating engineers more than any single command:

1. New AOS-CX interfaces are administratively down. Cisco switchports come up by default; an AOS-CX interface needs an explicit no shutdown. A translated config that omits it deploys cleanly and forwards nothing.
2. L2 vs routed defaults are platform-dependent. On campus platforms (6200/6300) interfaces default to Layer 2; on the data-center line (8100/8320/8325/9300) LAGs and ports come up as routed L3 interfaces. Verify with show interface brief rather than assuming — and make routing / no routing explicit in generated configs so the intent survives the platform.
3. Masks are CIDR. ip address 10.0.0.1/24, never 255.255.255.0. Converters handle this; hand-translation typos here are common.
4. Interface names are member/slot/port. GigabitEthernet1/0/1 becomes 1/1/1 — and on a VSF stack the first digit is the stack member, which matters the moment you mirror a multi-switch closet.

Spanning tree: RPVST+ to MSTP is a design decision, not a syntax swap

This is the one row of the table that deserves its own meeting. Cisco campuses overwhelmingly run Rapid PVST+ — one spanning-tree instance per VLAN. AOS-CX defaults to MSTP, where VLANs map onto a small number of shared instances. AOS-CX does support RPVST+ (spanning-tree mode rpvst, subject to per-platform VLAN instance limits), and during coexistence — Aruba access hanging off a Cisco core, or vice versa — running RPVST+ on the AOS-CX side keeps the interop simple.

The end-state design, though, is usually MSTP: group your VLANs into instances, set instance priorities so the root lands on the new core, and keep the region name, revision, and the full VLAN-to-instance mapping identical across every AOS-CX switch — the mapping is part of the region's configuration digest, so a single VLAN mapped differently on one switch quietly splits it into its own region. Whichever path you pick, the actual root placement under your actual VLAN layout is precisely the thing to verify in the lab rather than on the whiteboard, because a VLAN that lands in an unexpected instance inherits an unexpected root.

First-hop redundancy: HSRP to VRRP or VSX active-gateway

HSRP is Cisco-proprietary, so the gateway design must change. Two AOS-CX options:

Option 1 — VRRP, the like-for-like translation (active/standby, priorities, familiar failover semantics):

! Cisco IOS (HSRP)
interface Vlan10
 ip address 10.1.10.2 255.255.255.0
 standby 1 ip 10.1.10.1
 standby 1 priority 110
 standby 1 preempt

! Aruba AOS-CX (VRRP)
interface vlan 10
    no shutdown
    ip address 10.1.10.2/24
    vrrp 1 address-family ipv4
        address 10.1.10.1 primary
        priority 110
        no shutdown

Note both no shutdown commands — gotcha #1 applies to SVIs too (a newly created interface vlan is administratively down), and the VRRP instance itself is also disabled by default, so a translation that omits either parses cleanly and never answers for the virtual IP.

Option 2 — VSX active-gateway, the design Aruba actually recommends on a VSX core pair: both switches answer for the same virtual IP and MAC, active-active, with no FHRP election at all:

! Aruba AOS-CX — VSX primary member
interface vlan 10
    no shutdown
    ip address 10.1.10.2/24
    active-gateway ip mac 12:00:00:00:01:00
    active-gateway ip 10.1.10.1

The secondary member's config is identical except its own unique SVI address (say, 10.1.10.3/24). What's shared across the pair is the active-gateway IP and MAC — each member always keeps a distinct interface address, or you've configured a duplicate IP.

Which option maps from which source design depends on what the old core actually was. A Nexus vPC pair running HSRP translates naturally to VSX + active-gateway — the same active-active forwarding posture, minus the FHRP election. A VSS or StackWise Virtual core is a different starting point: it was one logical switch, so there was no FHRP running between its members at all — moving to VSX splits that into two independent control planes, and active-gateway is what restores the single-gateway experience for hosts. A standalone core pair on HSRP can go to either VRRP or active-gateway. In every case the failover behavior is measurable in the lab, and should be.

Build the mirror lab from a prompt

The traditional version of "test it first" is the DIY chain: a hypervisor, an EVE-NG or GNS3 install, image uploads, days of topology wiring. It works — plenty of migrations have been saved by it — but it's enough friction that most translated configs go to the maintenance window having never converged anywhere.

The agent-first version is a prompt. In NetPilot, you describe the migration, and the agent designs the topology, generates the configs, and deploys both estates:

"Build a migration lab: current state is a Cisco core pair with HSRP on VLANs 10/20/30 and two access switches on port-channels running RPVST+. Target state is the same topology on Aruba AOS-CX — VSX core with active-gateway, LAGs to access, MSTP with VLANs 10/20 in instance 1 and 30 in instance 2. Here are the sanitized IOS configs; translate them and flag anything that doesn't map cleanly."

Three things about how that lab comes up:

• It runs real network OS code, not simulation. NetPilot's supported lineup is 9+ network OSes and growing: Nokia SR Linux, FRR, and Linux are built in on every plan; Cisco IOL, Juniper cRPD, and Arista cEOS come in via bring-your-own-image (BYOI). Aruba AOS-CX sits in the custom-vendor tier — NetPilot is built on ContainerLab, and on the enterprise plan any ContainerLab-compatible image, the AOS-CX simulator included, is built into a dedicated environment for you. The image itself comes from HPE: the AOS-CX Switch Simulator is distributed at no charge through the HPE Networking Support Portal (a free account is required) — NetPilot never distributes vendor images; you source the simulator under your own account, and once it's built in, the agent deploys it like any other node. The Cisco side rides on your IOS image (BYOI), or on FRR stand-ins where exact IOS behavior isn't the question.
• It can mirror the real network, not a sketch of it. NetBox and Nautobot connectors are built in — the agent reads your source of truth and pulls the actual VLAN and interface inventory it's mirroring. On Signature and Enterprise plans, NetPilot connects to your Git repo or anything else MCP-enabled, so the "current state" side is built from the configs production actually runs, not from memory.
• The translation gets flagged, not just performed. The agent's job in the prompt above isn't only to emit AOS-CX syntax — it's to surface the rows that don't map cleanly: the HSRP group that should become active-gateway rather than VRRP, the RPVST+ VLAN that needs an MSTP instance decision, the interface that will come up shut down.

Direct CLI is always available. Every device in the lab — AOS-CX and Cisco alike — is a real NOS with SSH access. Type show spanning-tree on the simulator yourself; the agent workflow is the fast path, not a wall between you and the boxes.

Validate the migration: prove the translated configs behave

Translation gets you configs that parse. Validation proves they behave. Three checks cover most of the migration risk, and they're the same three whether the lab is agent-run or hand-run — the pattern is the one we use for network change validation generally, applied to a whole-estate swap.

1. Diff the routing tables.

"Capture the full routing table and OSPF neighbor state from the Cisco side, then from the AOS-CX side. Diff them — every prefix, next-hop, and metric. Flag anything that differs beyond the interface renames."

The agent runs the per-vendor commands (show ip route and show ip ospf neighbor translate across both platforms almost unchanged), normalizes the output, and reports the delta. A missing prefix here is a translation error caught in the lab instead of a helpdesk queue. To verify by hand, SSH into either side and compare the tables yourself — the AOS-CX output format differs cosmetically, which is exactly why the normalized diff is worth automating.

2. Verify the spanning-tree root.

"For every VLAN, show me which bridge is root on the old side and which is root on the new MSTP design. Confirm instance 1 and instance 2 roots are the VSX pair, and list any port that went blocking that wasn't blocking before."

This is where RPVST+-to-MSTP mistakes surface — a VLAN mapped to the wrong instance, a region mismatch splitting the topology, a priority left at default so an access switch wins root. show spanning-tree on both platforms confirms it manually.

3. Fail things under a continuous ping.

"Start continuous pings across the gateway and through the LAGs. Then: fail the VSX primary, restore it, drop one LAG member, restore it. Report seconds of loss for each event."

Gateway failover is the behavior your users actually experience during cutover, and it's the one a spreadsheet can't predict. Active-gateway should show near-zero loss on a VSX member failure — should is the word the lab replaces with a number. The same rehearsal discipline applies to the cutover runbook itself — step ordering, timed convergence, a tested rollback — which we covered in depth in the network cutover rehearsal walkthrough.

The output of the three checks is the artifact your change board wants: a routing diff with zero unexplained deltas, root placement matching the design, and measured failover times — evidence the translated network behaves, produced before the window opens.

Comware and ProCurve: the other half of the installed base

Plenty of "Cisco to Aruba" projects are actually HPE-to-HPE: retiring Comware (H3C-lineage 5xxx/7xxx/12xxx) or ProCurve/ArubaOS-Switch estates onto AOS-CX. The translation table changes shape:

Two of those rows hide real design work:

• Hybrid ports don't exist on AOS-CX. Comware's hybrid mode allows multiple untagged VLANs on one port (the trick behind MAC- and protocol-based VLAN assignment). An AOS-CX trunk carries exactly one untagged VLAN — vlan trunk native — plus tagged members. Most hybrid ports translate cleanly to native-plus-tagged; the ones using multiple untagged VLANs need a redesign (usually toward 802.1X/MAC-auth dynamic VLAN assignment), and you want to find them before the converter silently flattens them.
• IRF splits into two technologies. Comware's IRF virtualized both access stacks and core pairs into one logical switch. On AOS-CX that's two different answers: VSF for campus stacking on 6200/6300, VSX for the core — and VSX is not a single logical switch but two independent control planes with synchronized state, which changes how upgrades and split-brain scenarios behave. That difference is a first-class thing to rehearse in the mirror lab.

ProCurve/ArubaOS-Switch estates flip a different habit: the config model is VLAN-centric (vlan 10 … untagged 1-24 … tagged 25-26) where AOS-CX is port-centric. A ProCurve trunk 25-26 trk1 lacp becomes an AOS-CX interface lag 1 with lacp mode active. The commands are simple; the mental-model inversion is what a few hours against the simulator fixes — every port's VLAN membership has to be restated from the port's point of view, which is exactly the kind of mechanical rewrite worth handing to an agent and then spot-checking.

What a virtual lab can't test

Honest scope, because a migration plan that leans on a lab for things the lab can't show is worse than no lab:

• ASIC and dataplane behavior. The AOS-CX Switch Simulator runs the real control plane — OSPF, BGP, MSTP, VSX, the REST API — but forwarding is software. Hardware-dependent behavior (QoS queuing at congestion, TCAM capacity limits, hardware rate limiting) won't reproduce.
• Optics, cabling, and PHY. Transceiver compatibility, DAC quirks, and link-training issues only exist on metal. Keep your optics matrix as a hardware checklist item.
• Line-rate performance. The simulator is not a traffic-performance platform; don't benchmark throughput on it. (Our traffic generator comparison covers what software-tier testing can and can't claim.)
• PoE, physical stacking, and platform-specific hardware. VSF cabling, PoE budgets, and per-model port behavior need the pilot closet.

What the lab does cover is the part that causes most blown migration windows: config-translation errors, STP topology surprises, LACP negotiation failures, FHRP behavior changes, and routing deltas. The pattern that works: validate control-plane behavior exhaustively in the virtual mirror, then run a one-closet hardware pilot for the physical checklist, then cut over in stages. The lab doesn't replace the pilot — it makes the pilot boring.

FAQ

Is there an Aruba AOS-CX lab or sandbox for testing a Cisco or Comware migration?

Yes. HPE distributes the AOS-CX Switch Simulator at no charge through the HPE Networking Support Portal (a free account is required) — it runs the real AOS-CX network operating system as a VM, so translated configs, OSPF/BGP behavior, MSTP roots, LAG negotiation, and VSX active-gateway failover can all be tested before cutover. You can run it yourself in EVE-NG, GNS3, or containerlab, or have NetPilot build it into a dedicated cloud environment on the enterprise plan, where the agent builds the Cisco-or-Comware current state and the AOS-CX target side by side and runs the validation checks for you.

Can I run an Aruba CX emulator in EVE-NG or GNS3, or is there a cloud option?

Both paths work. The official AOS-CX Switch Simulator ships as an OVA for desktop hypervisors; to run it in EVE-NG you extract the virtual disk and convert it to QCOW2 for EVE-NG's image directory, and GNS3 pairs its appliance template with the extracted disk. That suits a self-hosted lab if you already run a hypervisor with enough RAM. The cloud option skips the hypervisor: NetPilot is built on ContainerLab, and on the enterprise plan any ContainerLab-compatible image — the AOS-CX simulator you download from HPE included — is built into a dedicated environment for you, with an AI agent that builds the topology from a plain-English prompt and full SSH access to every device. The mirror lab deploys in about 2 minutes.

Is there a config translator from Cisco IOS to Aruba AOS-CX?

There is no official automated HPE online config translator. HPE publishes the CLI Reference Guide for ArubaOS-CX, ArubaOS-Switch, Comware, and Cisco IOS mapping all four command sets side by side — a manual reference, not a converter. Third-party tools exist: netconverter.ai translates Catalyst configs to AOS-CX automatically, including RPVST+-to-MSTP instance mapping, and general-purpose AI assistants can draft translations. Whatever produces the config, translation is step one — the translated config still needs a lab to prove the STP topology, LACP negotiation, and gateway failover behave before the maintenance window.

How do I validate translated AOS-CX configs before cutover?

Build a mirror lab of the affected segment on real network OS images, deploy the current Cisco or Comware state next to the translated AOS-CX target, and run three checks: diff the routing tables between old and new, verify the spanning-tree root landed where the design says, and fail the uplinks and gateway pair under a continuous ping to measure real convergence. In NetPilot, the agent deploys both sides from your configs, runs the diff and failover battery, and reports the deltas — with SSH access to verify any result by hand.

Rehearse the swap before the window opens

Translation tools — this table included — get you a config that parses. The migrations that go smoothly are the ones where somebody made the translated network converge somewhere safe first, watched the STP root land, and put a number on the failover.

Paste your sanitized configs at app.netpilot.io and ask for the mirror — current estate on one side, AOS-CX target on the other, validation battery across both.

Copy-paste ready: the vendor-migration rehearsal prompt builds a parallel-run migration lab with equivalence checks before cutover — paste it into app.netpilot.io and swap the target vendor for your AOS-CX image.

Related: Network migration lab · Network change validation · Network cutover rehearsal