Cisco to Arista EOS Migration Cheat Sheet

If your team knows Cisco IOS, learning Arista EOS is mostly a matter of mapping familiar commands to their EOS equivalents. Because EOS ships a Cisco-style CLI, many show commands are identical, but there are important differences — show processes top once instead of show process cpu, no DTP, VRRP instead of HSRP, and Linux-based bash access for deep troubleshooting. This cheat sheet condenses the essential command mapping so migration and daily operation go smoothly.

The tables are organised by the task you are actually trying to complete, not by command family, so you can work top to bottom during a migration or jump straight to the section you need. Everything marked "same" is genuinely identical syntax, which is the majority of the read-only command set.

Why the CLI Looks Familiar

EOS was written from the start to be operationally familiar to IOS engineers, and the read path is deliberately near-identical: show running-config, show interfaces, show ip interface brief, ping and traceroute behave the same on both platforms. What differs is underneath. EOS is a Linux system with a modular set of agents, each managing one feature, communicating through a central state database. That design is what makes a feature process restartable in place rather than fatal to the switch, and it is also why the Linux toolchain is a first-class troubleshooting surface rather than a hidden debugging mode.

Interface Naming and Physical Layer

The naming change is the single most common source of copy-paste mistakes during migration. A 25G and a 100G port are both Ethernet; the media type and negotiated speed are visible in show interfaces status, not in the interface name. Breakout ports appear as consecutive Ethernet numbers rather than a subinterface of the parent.

System and Process Commands

show processes top once is worth internalising early: it gives a CPU snapshot with per-agent attribution, which is more useful than a flat process table because each EOS agent maps to a feature. On a busy control plane it will immediately show whether BGP, the CLI agent or the state database is consuming the scheduler.

L2 and VLAN Commands

Two L2 differences bite in practice. There is no DTP on EOS, so a trunk is a trunk because you configured it and not because it negotiated — a port set to switchport mode access will never become a trunk even if the far end asks. And LLDP replaces CDP entirely: if you are migrating and your monitoring polls show cdp neighbors, that script needs rewriting before the change window, not after.

L3 and Routing Commands

Masks are the other major syntax shift: EOS uses CIDR prefix length everywhere, including routing protocol network statements, static routes and ACL entries. The wildcard-mask pairs of IOS simply do not exist, which removes a whole class of address-arithmetic bugs but does require care when translating large rule sets by hand.

First-Hop Redundancy: HSRP to VRRP

! Cisco IOS - HSRP
interface Vlan10
 ip address 172.16.1.2 255.255.255.0
 standby 1 ip 172.16.1.1
 standby 1 priority 110
 standby 1 preempt

! Arista EOS - VRRP
interface Vlan10
 ip address 172.16.1.2/24
 vrrp 1 ip 172.16.1.1
 vrrp 1 priority 110
 vrrp 1 preempt

Both are virtual-router protocols and both fail over in a few seconds, but they are not the same protocol and they will not form a pair with each other. If a migration is incremental and one side must remain on HSRP, you need either a partial cutover with a different gateway design or a maintenance window; you cannot bridge HSRP and VRRP on the same subnet and expect redundancy to work.

Security, AAA and Management Access

The most visible difference is that EOS has no line vty configuration. SSH is a managed service under management ssh, and the HTTPS API is a managed service under management api http-commands. Both are on by default on a fresh EOS switch and both can be scoped to a VRF, which is a much cleaner way to build an out-of-band management plane than filtering VTY lines with ACLs.

QoS, ACL and Logging Syntax

The filtering operator change is easy to miss: EOS accepts both grep and include in most contexts, but scripts written for one platform sometimes break on the other. Standardising on grep is the safer choice because it is the native Linux-style operator in EOS and removes any ambiguity when you pipe output into automation.

Logging and Troubleshooting Depth

Read-only troubleshooting maps cleanly between the two platforms, and the differences are mostly about how much detail you can reach without opening a support case. EOS exposes the full Linux toolchain, which means a congestion problem that would require a packet capture at a tap on IOS can be diagnosed directly on the switch.

That last row is worth dwelling on. On IOS, deep packet-level analysis usually means mirroring a port to an external capture appliance, because debug ip packet on a busy device risks taking it down. On EOS you write a filter and watch packets directly, with no impact on the forwarding path, which shortens the average time to root cause considerably on complex issues such as asymmetric routing, MTU black holes and silent control-plane drops.

Architecture Differences That Matter

• OS model: IOS is a proprietary monolithic OS; EOS is modular, built on Fedora Linux with independent multi-process agents.
• Failure handling: a feature failure can crash an IOS device; in EOS a process restarts without taking the switch down.
• CLI parity: the EOS CLI deliberately mimics Cisco IOS — show running-config, show interfaces, show ip interface brief, ping, and traceroute work the same on both.
• Debugging depth: EOS exposes a real bash shell, so standard Linux tools (ps, strace, tcpdump) are first-class troubleshooting tools.
• Configuration safety: EOS supports configuration sessions with a diff review and a timed auto-rollback; on IOS the equivalent is an archive-based configure replace with no automatic rollback.
• Programmability: JSON output for several hundred show commands and a built-in HTTPS API ship by default, rather than requiring a separate automation licensing tier.

Working in bash Without Breaking the Switch

Dropping into the shell is one of the genuine advantages of EOS, and it is also the fastest way to cause an outage if it is used carelessly. The read-only tools are safe and extremely useful:

bash
df -h
free -m
ps aux | head
sudo tcpdump -i et1 -c 20 port 179
ls -al /mnt/flash
sudo lsof -i :443

Packets captured with tcpdump straight on the switch control plane are often the difference between a two-day vendor case and a five-minute answer. Keep the filter tight, cap the packet count, and never edit or delete files in /mnt/flash from the shell unless you are certain what owns them.

Migration Checklist

• Rewrite every tool and script that parses IOS output — interface names, mask format and CDP/LLDP are the usual breakers.
• Convert HSRP to VRRP on both sides of every redundant gateway; do it in one window per subnet.
• Replace show interfaces trunk with show interfaces switchport in run books and monitoring.
• Remove reference to DTP and dynamic switchport modes from standards documents; on EOS every port mode is explicit.
• Move AAA from local to TACACS+/RADIUS before the migration, not after, so the account model is identical on both platforms.
• Confirm SNMP, syslog and NTP reach the new switch from the management VRF — monitoring that was never tested is monitoring that does not work.

Related Articles

For hands-on EOS configuration, continue with our EOS VLAN, trunk and port-channel guide, the EOS troubleshooting cookbook, and the multi-vendor CLI cheat sheet covering IOS XR, Junos, SR OS and VRP.

Two further reads help with a migration project specifically: the Cisco vs Arista switch architecture and CLI comparison explains the design differences behind the command mapping, and the IOS to EOS VLAN and interface command mapping walks through the Layer 2 conversion in detail.

原文链接：https://cisconetsolutions.com/arista-eos-migration-cheat-sheet