Cisco to ArubaOS-CX Migration: Command Mapping

Migrating a campus from Cisco IOS to ArubaOS-CX is not a syntax swap: interface naming changes, masks become CIDR, ports come up administratively down, and the high-availability model moves from stacking/VSS to VSF and VSX. Translation is the easy half; the half that decides whether the cutover window is boring or infamous is proving the translated configuration behaves like the old one. This guide gives the translation table, the operational differences that cause most migration incidents, and the lab validation checks to run before touching production.

Command translation table

Two rows deserve emphasis. First, interface naming: on a VSF stack the first digit is the stack member, so mirrored closets translate to different port names than on a standalone chassis - handled by tooling, but it is where hand translations go wrong. Second, spanning tree: RPVST+ to MSTP is a design decision, not a syntax change. If the two environments must interoperate during the migration, run spanning-tree mode rpvst on the CX side so the root is elected consistently and you do not create two STP domains that both believe they are root.

Operational differences that cause incidents

• VLAN creation is harmless, but port state is not: IOS access ports come up shut; CX ports are down when created and require an explicit no shutdown. Script generators that copy the old config produce interfaces that never come up.
• Masks are CIDR everywhere. ip address 10.0.0.1/24, never 255.255.255.0. Converters usually handle it; hand translation does not.
• Make routing explicit. An interface in CX is L2 or L3 based on routing / no routing; leaving it implicit is how you get an SVI where a routed port was intended (or the reverse).
• Active-active changes the design. Replacing a VSS/StackWise pair with VSX means the keepalive link is a separate concern, and the gateway model becomes VSX active-gateway rather than HSRP.
• MAC address tables and ARP timeouts differ; verify dual-homed servers behave under failover instead of assuming.

Build the lab before the window

# minimal two-switch lab with a server and a router peer
docker run --rm -it --privileged ghcr.io/srl-labs/containerlab:latest
# or virtual switches / CX simulator + a Linux host for traffic

Load the translated configs, then verify in this order:

1. Converge: every interface that should be up is up, and LAGs reach the selected/forwarding state.
2. STP: the root bridge lands where the design says it should - check show spanning-tree on both platforms and the root cost per VLAN.
3. Gateway failover: kill the primary uplink and measure the failover time against the SLA rather than assuming sub-second.
4. Traffic: run real flows between VLANs, not ICMP only; test jumbo frames and the MTU end to end.
5. Management: confirm SNMP, syslog, AAA and NTP all work from the new box before it goes into production.

Cutover sequencing

• Migrate leaf/access switches before the distribution/core, and keep the STP root where it is until the access layer is stable.
• Keep a one-switch rollback: label the old configuration, and do not decommission the Cisco device until the new one has passed a full business cycle.
• Translate with a tool but review every line - generated configs hide intent, especially around routed ports and VLAN lists.
• Document the mapping table for your own environment; the next migration takes a fraction of the time.

Related: ArubaOS-CX access vs trunk ports, Cisco IOS to Arista EOS command mapping, and ArubaOS-CX VSX split-brain recovery.

原文链接：https://netpilot.io/blog/cisco-to-aruba-migration-lab