Arista EOS CLI vs Cisco IOS Key Differences

Two CLIs, One Goal — But the Path Couldn't Be More Different

If you've spent years on Cisco IOS and you're suddenly handed an Arista switch, the first thing you'll notice is how familiar it feels. The CLI structure looks similar — you've got your

enable

, your

configure terminal

, your

show

commands. But spend more than ten minutes on it and you'll start finding the edges. The mental model underneath EOS is fundamentally different from IOS, and those differences compound quickly when you're building production networks.

This isn't a "Arista is better than Cisco" piece. Both platforms have their place. What I want to do is give you a clear map of where the two diverge — mechanically, operationally, and philosophically — so you're not caught off guard when a familiar command does something unexpected or simply doesn't exist at all.

The Underlying OS Model

Arista EOS runs on top of a standard Linux kernel. This is not marketing copy — it has real, practical consequences. When you SSH into an Arista switch, you're interacting with a shell process sitting on Linux. You can drop straight into the Linux bash shell from the EOS CLI using the

bash

command. Try that on a Cisco IOS box and you'll be disappointed. IOS-XE does run on Linux under the hood, but it abstracts the operating system almost completely away from the operator. EOS exposes it. That's a design philosophy difference that runs through everything else.

! Arista EOS — drop to bash directly from the CLI
sw-infrarunbook-01# bash

Arista Networks EOS shell

[infrarunbook-admin@sw-infrarunbook-01 ~]$ ip addr show Management1
3: Management1: mtu 1500 state UP
    inet 10.0.1.10/24 brd 10.0.1.255 scope global Management1

On Cisco IOS-XE, the closest equivalent is

guestshell run bash

, but that's a containerized environment — you're not touching the host OS directly. On classic IOS, there's nothing equivalent at all.

The Configuration Commit Model — This Is the Big One

In Cisco IOS, configuration changes are applied immediately the moment you type them. There's no staging, no commit, no rollback. You type

no shutdown

and the interface comes up. You delete a route and traffic drops. Right now. This is what every IOS engineer has internalized, and it's also the source of countless production outages from fat-fingered commands.

Arista EOS uses the same immediate-apply model by default, so that muscle memory carries over. But EOS also supports a confirmed commit model through the

configure session

feature, which lets you stage changes and commit them atomically. This is much closer to how Juniper JunOS operates and is a significant operational safety feature that IOS simply doesn't have.

! Arista EOS — staging changes with configure session
sw-infrarunbook-01# configure session MAINT-WINDOW-0408
sw-infrarunbook-01(config-s-MAINT-)# interface Ethernet3
sw-infrarunbook-01(config-s-MAINT-if-Et3)# shutdown
sw-infrarunbook-01(config-s-MAINT-if-Et3)# exit
sw-infrarunbook-01(config-s-MAINT-)# show session-config diffs
--- system:/running-config
+++ session:/MAINT-WINDOW-0408
@@ -45,6 +45,7 @@
 interface Ethernet3
    description Uplink-to-Core
+   shutdown
sw-infrarunbook-01(config-s-MAINT-)# commit

! Cisco IOS — no session model, changes apply immediately
sw-infrarunbook-01(config)# interface GigabitEthernet0/3
sw-infrarunbook-01(config-if)# shutdown
! Done. Interface is down. No staged review, no rollback.

The

configure session

workflow also supports rollback timers. If your commit causes a problem and you lose connectivity, EOS can auto-revert after a configurable timeout. In my experience, this feature alone justifies the migration for teams that do frequent maintenance windows on production gear. I've watched it save an engineer who fat-fingered an OSPF passive-interface statement at 2 a.m. and lost his management path — EOS reverted cleanly after 60 seconds.

Interface Naming — Where the Confusion Starts

This seems minor but it trips people up constantly in day-to-day work. Cisco IOS uses long-form interface names that can be abbreviated:

GigabitEthernet0/1

, shortened to

Gi0/1

. Arista EOS uses a different naming convention entirely:

Ethernet1

,

Ethernet2/1

for breakout ports,

Management1

. For fixed-form switches there's no slot/port notation — it's just a flat interface number.

On modular Arista chassis like the 7800 series, you'll see

Ethernet1/1/1

for slot/module/port. But for the bread-and-butter platforms like the 7050 or 7280 series, it's

EthernetN

.

! Cisco IOS — GigabitEthernet naming convention
interface GigabitEthernet1/0/1
 description Server-Port-01
 switchport mode access
 switchport access vlan 100
 spanning-tree portfast

! Arista EOS — Ethernet naming convention
interface Ethernet1
   description Server-Port-01
   switchport mode access
   switchport access vlan 100
   spanning-tree portfast

Notice the three-space indentation inside the EOS interface block versus the single space from IOS. It's cosmetic, but it matters when you're diffing configs or feeding them into automation tools that do text comparisons. Don't let that catch you off guard in a script.

Port Channels and MLAG

Port channel configuration on both platforms is similar in concept. Cisco uses

channel-group

under the physical interface; Arista uses the same keyword. The output naming differs slightly — Arista capitalizes Port-Channel consistently.

! Cisco IOS — Port Channel
interface GigabitEthernet0/1
 channel-group 1 mode active

interface Port-channel1
 description LAG-to-Core
 switchport mode trunk
 switchport trunk allowed vlan 100,200,300

! Arista EOS — Port Channel
interface Ethernet1
   channel-group 1 mode active

interface Port-Channel1
   description LAG-to-Core
   switchport mode trunk
   switchport trunk allowed vlan 100,200,300

Where Arista diverges significantly from Cisco is with MLAG — Multi-chassis Link Aggregation. Cisco achieves something similar with vPC on NX-OS or VSS on certain Catalyst platforms, but neither of those run standard IOS. Arista MLAG is available across the entire fixed-form EOS product line, with a consistent configuration model regardless of which Arista platform you're on.

! Arista EOS — MLAG configuration on sw-infrarunbook-01
mlag configuration
   domain-id INFRARUNBOOK-MLAG
   heartbeat-interval 4000
   local-interface Vlan4094
   peer-address 10.255.255.2
   peer-link Port-Channel100
   reload-delay mlag 360
   reload-delay non-mlag 300

interface Vlan4094
   description MLAG-Peer-Link-VLAN
   ip address 10.255.255.1/30

interface Port-Channel100
   description MLAG-Peer-Link
   switchport mode trunk
   switchport trunk group MLACP

The MLAG peer presents a single bridge ID to downstream devices, which EOS handles automatically. There's no equivalent construct in standard IOS — and this matters enormously for data center access layer designs.

VLAN Configuration

Both platforms use the standard

vlan [id]

/

name [name]

database model, and both support

switchport

commands for L2 configuration. The surface-level syntax is close enough that most VLAN configs copy across with minor adjustments.

The deeper difference appears when you get into VXLAN overlays. In Arista EOS, VLANs map to VNIs explicitly through the VXLAN interface configuration. Cisco IOS-based switches don't have this concept at all — VXLAN with EVPN is a NX-OS or IOS-XE feature on specific hardware, and even there the configuration model differs.

! Arista EOS — VLAN to VNI mapping for VXLAN
vlan 100
   name Production-Servers

vlan 200
   name Storage-Replication

interface Vxlan1
   vxlan source-interface Loopback0
   vxlan udp-port 4789
   vxlan vlan 100 vni 10100
   vxlan vlan 200 vni 10200
   vxlan learn-restrict any

There's nothing in IOS that looks like this, because IOS platforms generally don't support VXLAN as a native construct. This is a platform capability gap that surfaces as missing CLI commands, not just syntax differences.

BGP Configuration — Similar DNA, Meaningful Details

BGP on EOS will feel familiar if you're coming from IOS. The basic neighbor statement, route-map application, network advertisement — it's all there. But the details diverge in ways that matter.

! Cisco IOS — Basic BGP configuration
router bgp 65001
 bgp router-id 10.0.0.1
 neighbor 10.0.0.2 remote-as 65002
 neighbor 10.0.0.2 description PEER-infrarunbook-spine01
 neighbor 10.0.0.2 update-source Loopback0
 neighbor 10.0.0.2 route-map RM-IN in
 neighbor 10.0.0.2 route-map RM-OUT out
 !
 address-family ipv4
  neighbor 10.0.0.2 activate
  network 10.10.10.0 mask 255.255.255.0

! Arista EOS — Basic BGP configuration
router bgp 65001
   router-id 10.0.0.1
   neighbor 10.0.0.2 remote-as 65002
   neighbor 10.0.0.2 description PEER-infrarunbook-spine01
   neighbor 10.0.0.2 update-source Loopback0
   neighbor 10.0.0.2 route-map RM-IN in
   neighbor 10.0.0.2 route-map RM-OUT out
   !
   address-family ipv4
      neighbor 10.0.0.2 activate
      network 10.10.10.0/24

Two differences stand out immediately. EOS uses CIDR notation (

10.10.10.0/24

) rather than the IOS dotted-decimal mask format. And in EOS the

router-id

command inside the BGP stanza drops the

bgp

prefix that IOS requires. These are small things that will fail silently if you copy-paste the wrong version.

EOS also supports BGP listen ranges and peer filters for dynamic neighbor discovery — a pattern that's common in spine-leaf fabrics running BGP as the underlay.

! Arista EOS — BGP dynamic peer discovery with listen range
router bgp 65001
   bgp listen range 10.0.0.0/8 peer-group LEAF-PEERS peer-filter LEAF-AS-RANGE
   !
   peer group LEAF-PEERS
      bfd
      send-community extended

peer-filter LEAF-AS-RANGE
   10 match as-range 65100-65199 result accept

There's no direct IOS equivalent for this. Dynamic BGP peer discovery on IOS requires BGP unnumbered support, which most IOS platforms don't offer in the same way. In a fabric with 20 leaf switches, that listen range approach saves a lot of manual neighbor configuration.

Show Commands and Operational State

This is where day-to-day friction lives. The show commands overlap significantly but the differences are enough to make muscle memory unreliable.

! Cisco IOS show commands
show interfaces GigabitEthernet0/1 counters
show mac address-table
show spanning-tree vlan 100
show ip bgp summary
show ip ospf neighbor
show etherchannel summary

! Arista EOS equivalents
show interfaces Ethernet1 counters
show mac address-table
show spanning-tree vlan 100
show bgp summary
show ip ospf neighbor
show port-channel summary

Note

show ip bgp summary

versus

show bgp summary

. EOS dropped the

ip

qualifier from BGP show commands because EOS treats BGP as address-family agnostic at the top level. Both commands actually work in EOS for backwards compatibility, but the canonical form is without

ip

. Also note

show etherchannel summary

becomes

show port-channel summary

— same concept, different keyword.

The bigger story here is what EOS adds that IOS doesn't have:

| json

output filtering directly in the CLI.

sw-infrarunbook-01# show interfaces Ethernet1 | json
{
    "interfaces": {
        "Ethernet1": {
            "name": "Ethernet1",
            "forwardingModel": "routed",
            "lineProtocolStatus": "up",
            "interfaceStatus": "connected",
            "mtu": 9214,
            "bandwidth": 10000000000,
            "description": "Uplink-to-Spine-01",
            "physicalAddress": "00:1c:73:ab:12:34"
        }
    }
}

Every show command in EOS supports

| json

. You can do this on IOS-XE via YANG models and NETCONF, but it's not a native pipe option at the CLI level. For automation and monitoring workflows, the EOS approach is dramatically simpler to get started with.

eAPI — The Automation Hook IOS Doesn't Have

Arista EOS includes a built-in HTTP/HTTPS API called eAPI. Once enabled, every CLI command is accessible via JSON-RPC over HTTPS. You don't need NETCONF, you don't need an agent, you don't need anything special — just HTTP.

! Arista EOS — Enable eAPI on sw-infrarunbook-01
management api http-commands
   protocol https
   no shutdown
   !
   vrf management
      no shutdown

From that point, any tool that can make an HTTP POST — Python, curl, Ansible, Terraform — can run CLI commands against the switch and get back structured JSON. I've built monitoring integrations in under an hour using just the Python

requests

library and eAPI. No vendor SDK required.

Cisco has RESTCONF and NETCONF on IOS-XE, which are standards-based and more portable across vendors. But they require YANG model knowledge and a meaningfully more complex toolchain to get started with. EOS eAPI trades portability for simplicity — and for teams that run Arista exclusively, the tradeoff is an easy one to make.

AAA and the Management Plane

AAA configuration in EOS follows the same general model as IOS — RADIUS or TACACS+ for authentication, authorization groups, accounting. The commands are similar enough that a working TACACS+ config from IOS will port over with minimal changes.

! Cisco IOS — TACACS+ AAA
aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
tacacs server TACACS-PRIMARY
 address ipv4 10.0.1.100
 key 7 080F7B6E5A4F
 timeout 3

! Arista EOS — TACACS+ AAA
aaa authentication login default group TACACS-SERVERS local
aaa authorization exec default group TACACS-SERVERS local
!
tacacs-server host 10.0.1.100 key 7 080F7B6E5A4F timeout 3
!
aaa group server tacacs+ TACACS-SERVERS
   server 10.0.1.100

One EOS behavior worth understanding: role-based access control in EOS uses Linux user groups under the hood. When you create a local user in EOS, you're creating a Linux user. When you assign a role, you're assigning group membership. That means if AAA fails catastrophically and you need to recover via console, you're working with standard Linux user mechanics — which is both reassuring and something to account for in your security model.

Common Misconceptions

The biggest one I encounter from IOS engineers is the belief that EOS is "just Cisco with different spacing." It isn't. The CLI familiarity is intentional — Arista was founded by ex-Cisco engineers and the surface-level similarity lowers the onboarding barrier. But the Linux base means logging goes to syslog in a fully POSIX-compliant way, processes can crash and restart without rebooting the switch, and core dumps are readable files on disk. None of those are IOS behaviors.

The second misconception is around

write memory

. EOS supports it for compatibility, but the canonical command is

copy running-config startup-config

, and the separation between running and startup config is cleaner in EOS than IOS. If you're using configure sessions, your staged changes never appear in the running config until you explicitly commit — so

show running-config

gives you a clean picture of what's actually active, not a partially-typed maintenance window.

A third one: some engineers assume EOS doesn't do STP well because Arista is known for data center switching. That's wrong. MSTP, RSTP, and Rapid-PVST are all supported, and the commands map closely to IOS. Where EOS differs is in MLAG integration — the MLAG pair presents a single bridge ID automatically, which eliminates the per-VLAN STP tuning you'd need to do manually with vPC on NX-OS.

A Real-World Side-by-Side on sw-infrarunbook-01

Here's a practical config comparison for a routed uplink in a spine-leaf fabric — the kind of interface you'll configure hundreds of times on a DC leaf switch.

! Arista EOS — Routed uplink to spine on sw-infrarunbook-01
interface Ethernet49/1
   description Uplink-to-Spine-01 10.0.0.0/31
   no switchport
   mtu 9214
   ip address 10.0.0.0/31
   bfd interval 300 min-rx 300 multiplier 3
   isis enable UNDERLAY
   isis circuit-type point-to-point
   isis metric 10

! Cisco IOS — Equivalent routed uplink
interface GigabitEthernet1/0/49
 description Uplink-to-Spine-01 10.0.0.0/31
 no switchport
 mtu 9214
 ip address 10.0.0.0 255.255.255.254
 bfd interval 300 min_rx 300 multiplier 3
 ip router isis UNDERLAY
 isis circuit-type point-to-point
 isis metric 10

Count the differences: CIDR vs dotted-decimal mask, BFD syntax uses a hyphen in EOS (

min-rx

) versus an underscore in IOS (

min_rx

), and IS-IS enablement is

isis enable PROCESS

in EOS versus

ip router isis PROCESS

in IOS. None of these are difficult — but each one is a trip hazard if you're moving fast, and none of them will tell you clearly what's wrong when the command fails to parse.

Knowing these differences ahead of time — not just the high-level "EOS runs on Linux" talking point — is what separates engineers who can switch between platforms confidently from those who need 20 minutes and a search engine for every config block. Both platforms are capable. EOS gives you more direct access to the underlying system and a better automation story out of the box. IOS has decades of tooling, training material, and operational familiarity behind it. The right answer for most teams is knowing both well enough to use neither as a crutch.