Cisco IOS to Arista EOS: VLAN and Interface Command Mapping

Arista EOS feels familiar to Cisco engineers because its CLI was deliberately modeled on IOS, but the differences that do exist will bite you during a migration - interface naming without speeds, CIDR addressing on every L3 interface, port-channel instead of EtherChannel, and VRRP instead of HSRP. This command-mapping guide translates the configuration blocks you use every day on Cisco IOS into their Arista EOS equivalents, so a data center or campus migration stops being a guessing game.

Global and Management Configuration

The session flow is identical: enable, configure terminal. Management access differs slightly in EOS, which separates SSH, Telnet and HTTP services into their own management contexts:

! Cisco IOS
enable secret MySecret
username admin privilege 15 secret MySecret
ip domain-name example.net
crypto key generate rsa
ip ssh version 2
line vty 0 4
 transport input ssh

! Arista EOS
enable secret MySecret
username admin privilege 15 secret MySecret
ip domain-name example.net
management ssh
 idle-timeout 5
 no shutdown

EOS also has management api http-commands for the eAPI, which is how most automation talks to Arista switches.

VLAN and Switchport Configuration

VLAN creation is nearly identical. EOS uses CIDR-style configs everywhere and interface names without speed prefixes:

! Cisco IOS
vlan 10
 name wireless
interface GigabitEthernet1/0/1
 switchport mode access
 switchport access vlan 10
interface GigabitEthernet1/0/2
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10-12

! Arista EOS
vlan 10
 name wireless
interface Ethernet1
 switchport mode access
 switchport access vlan 10
interface Ethernet2
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10-12

Port-Channel / EtherChannel

EOS uses channel-group <id> mode active plus an explicit port-channel interface, and the L3 form relies on no switchport:

! Arista EOS: L2 port channel
interface Ethernet1-2
 switchport mode trunk
 switchport trunk allowed vlan 10-12
 channel-group 1 mode active
interface port-channel 1
 switchport mode trunk
 switchport trunk allowed vlan 10-12

! Arista EOS: L3 port channel
interface Port-Channel1
 no switchport
 ip address 192.168.1.1/24
interface Ethernet1-2
 channel-group 1 mode active

SVIs, Routing and First-Hop Redundancy

SVI syntax is the same keyword (interface vlan) but the address is CIDR, and inter-VLAN routing needs ip routing enabled globally:

! Arista EOS
ip routing
interface vlan 10
 ip address 172.16.1.1/24
 no shutdown

! First-hop redundancy: EOS uses VRRP (not HSRP)
interface vlan 10
 vrrp 1
  ip 172.16.1.3
  priority 110
  preempt

Security and Spanning-Tree Building Blocks

! EOS: PVST+ is replaced by rapid-pvst mode (RPVST+ itself is not supported)
spanning-tree mode rapid-pvst
interface Ethernet1/1
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
 spanning-tree bpduguard enable

! EOS: ACL syntax supports both numbered and named styles
ip access-list extended WEB-FILTER
 permit tcp 192.168.1.0/24 any eq 443
 deny ip 192.168.1.0/24 172.33.2.0/24
 permit ip any any
interface Ethernet1/1
 ip access-group WEB-FILTER in

Verification Commands and Automation Notes

• Verify switchport state: show interfaces switchport (EOS prints admin mode, operational mode, native VLAN and allowed VLAN list).
• Structured output: append | json to show commands for automation - for example show interfaces status | json.
• Command pipelining: show running-config | include hostname.
• Config sessions: EOS supports configuration sessions with commit/rollback, which is the safe way to push large changes.
• Saving: write memory or copy run start both work.

Related reading: Arista EOS VLAN, trunk, SVI and port-channel runbook and Arista EOS port-channel LACP configuration.

Interface naming, ranges and the missing speed prefix

The first thing that trips up a Cisco engineer is that EOS interface names carry no speed. Ethernet1 may be 10G, 25G or 100G, and the speed is discovered with a show command rather than encoded in the name. This is deliberate: Arista's argument is that the name should identify the port, not the optic currently plugged into it.

! Cisco IOS                        ! Arista EOS
interface GigabitEthernet1/0/1     interface Ethernet1
interface TenGigabitEthernet1/1/1  interface Ethernet2
interface TwentyFiveGigE1/0/1      interface Ethernet3
interface Port-channel1            interface Port-Channel1
interface Vlan10                   interface Vlan10

! Range syntax - both platforms understand expanded and range forms
interface GigabitEthernet1/0/1-4   interface Ethernet1-4
interface range Gi1/0/1 - 4        interface Ethernet1-4

! Confirm what a port actually negotiates
show interfaces status | include Gi  show interfaces Ethernet1 | include rate

Note the capitalisation: EOS spells the L3 aggregate Port-Channel1 with capitals, while the channel-group command and the L2 aggregate interface reference use lowercase port-channel. EOS accepts either in most contexts, but the running configuration normalises to Port-Channel and matching that exactly avoids surprises in automation diffs.

Addressing, speed and duplex differences

Every L3 interface in EOS takes CIDR notation. IOS XE also accepts a mask, so a migration script that parses IOS output will produce EOS config that fails to load unless it is converted.

! Cisco IOS                              ! Arista EOS
interface Vlan10                         interface Vlan10
 ip address 172.16.1.1 255.255.255.0      ip address 172.16.1.1/24
interface GigabitEthernet1/0/1            interface Ethernet1
 speed 1000                               speed forced 1000full
 duplex full                              no speed auto   ! for fixed speed
 no shutdown                              no shutdown

! Verification
show ip interface brief                   show ip interface brief
show interfaces Gi1/0/1 | include duplex  show interfaces Ethernet1 | include duplex

Speed and duplex differ more than the addressing does. EOS uses speed forced 1000full to pin the negotiation, where IOS uses separate speed and duplex statements. On EOS you cannot disable autonegotiation on copper the way IOS lets you, so the forced keyword is how a fixed-speed copper link is expressed.

Trunk, native VLAN and the switchport defaults

! Cisco IOS
interface GigabitEthernet1/0/2
 switchport mode trunk
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10-12,20
 switchport nonegotiate

! Arista EOS
interface Ethernet2
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10-12,20
 switchport trunk allowed vlan add 30
 ! no switchport trunk encapsulation - EOS is dot1q only
 ! no switchport nonegotiate - DTP does not exist in EOS

Two IOS commands simply have no EOS equivalent because the underlying feature does not exist. switchport trunk encapsulation dot1q is meaningless on a platform that only speaks 802.1Q, and switchport nonegotiate has nothing to disable because EOS does not implement DTP. Deleting them from the template rather than translating them is the correct move. Native VLAN handling is identical on both, including the default of VLAN 1, which is why the recommendation to change it transfers unchanged.

VLAN translation and selective QinQ are expressed differently again, with EOS offering a dedicated vlan translation profile - the EOS syntax is covered in Arista EOS VLAN translation and dot1q tunnel.

Show command mapping

! Task                        Cisco IOS                        Arista EOS
! Interface summary           show ip interface brief           show ip interface brief
! Detailed interface          show interfaces Gi1/0/1           show interfaces Ethernet1
! Switchport detail           show interfaces switchport        show interfaces switchport
! MAC table                   show mac address-table            show mac address-table
! STP per interface           show spanning-tree interface      show spanning-tree interface
! Port-channel                show etherchannel summary         show port-channel
! LACP neighbours             show lacp neighbor                show lacp neighbor
! VLAN list                   show vlan brief                   show vlan
! Config diff                 show archive config differences    show diff

Two of these are worth internalising. show port-channel replaces the entire show etherchannel family and prints the members, the protocols and the operational state in one screen. show diff compares the running configuration against the startup configuration, replacing show archive config differences with a much simpler command.

Configuration sessions, commit and rollback

This is the largest operational difference between the platforms, and it is the one most worth adopting during a migration. EOS can stage changes in a configuration session, review the diff, and commit or roll back atomically. IOS has no equivalent on most platforms.

configure session vlan-migration
! make changes
show session-config diffs
commit
! or
abort

Because sessions can be committed and rolled back by name, they also make an excellent safety net for bulk changes pushed by automation: create the session, apply the change, review the diff, and only then commit. The same pattern with the eAPI and a Python client is the basis of most Arista automation and is covered in Arista EOS tap aggregation and tool ports for a worked example. For teams migrating multiple vendor platforms at once, the mapping exercise generalises - see the H3C Comware versus Huawei VRP command mapping.

Port-channel modes, LACP timers and replacing PAgP

This is the migration item most likely to be forgotten. Cisco IOS offers three EtherChannel modes across two protocols: LACP active/passive, PAgP desirable/auto, and on for a static bundle. EOS supports LACP active and passive plus the static form, but has no PAgP implementation at all. Every channel-group N mode desirable line has to become channel-group N mode active, and the peer must also be set to active, because two passive sides will never negotiate a bundle.

! Cisco IOS: PAgP bundle                ! Arista EOS: the only correct translation
interface range Gi1/0/1-2               interface Ethernet1-2
 channel-protocol pagp                   channel-group 1 mode active
 channel-group 1 mode desirable
                                        interface Port-Channel1
interface Port-channel1                  switchport mode trunk
 switchport mode trunk

! Static bundles exist on both, and neither end will detect a member mismatch
interface Ethernet1-2
 channel-group 1 mode on

LACP timer behaviour is called rate on both platforms and means the same thing: host and switch must agree on slow (30 s) or fast (1 s). On EOS the rate is configured under the physical member interface rather than on the port-channel, and setting it in the wrong place and then wondering why failover takes half a minute is a classic migration bug. The Linux side of the identical equation, including how to verify the negotiated rate from /proc/net/bonding/bond0, is covered in Linux bonding 802.3ad, LACP rate and hash policy.

eAPI and the automation surface

EOS exposes every show and configuration command as JSON, which changes the verification step of a migration more than any other feature. Instead of capturing CLI text and writing fragile regular expressions, an automation job can request show interfaces status as structured data and assert on individual fields.

management api http-commands
 no shutdown
! then over HTTPS, from any language with an HTTP client
curl -k -u admin:secret https://switch/command-api \
  -d '{"jsonrpc":"2.0","method":"runCmds","params":{"version":1,
       "cmds":["show interfaces status"],"format":"json"},"id":1}'

Both platforms also accept | json at the CLI, so the structured format is available interactively as well as over the API - for example show interfaces status | json or show vlan | json. For a migration project that single feature is often what justifies the work on its own, because it turns post-change verification from a manual read-through into an assertion that fails loudly.

Migration checklist

1. Strip the obsolete commands first. Remove all switchport trunk encapsulation, nonegotiate, channel-protocol and channel-group mode desirable lines; PAgP has no EOS equivalent and mode active is the only sensible replacement.
2. Convert every mask to CIDR. Addresses, ACLs, and any prefix written as a dotted mask must be rewritten.
3. Rename verbs, not structure. The configuration hierarchy in EOS is close enough to IOS that block-by-block translation works; it is the keywords inside the blocks that change.
4. Replace HSRP with VRRP. There is no HSRP on EOS. VRRP group numbers, priorities and preempt map cleanly, and the virtual address becomes the only real decision.
5. Check the STP mode. EOS supports rapid-pvst as a mode name for compatibility with IOS configuration, but Arista's own implementation is MSTP-based. Verify that the intended topology is what actually converges rather than assuming the modes are identical.
6. Verify with | json. Any show command can be parsed as JSON, which means the verification step can be scripted instead of eyeballed.

Original article: https://www.cisconetsolutions.com/arista-eos-configuration-cheat-sheet/