Arista EOS Configuration Cheat Sheet: Commands That Matter

Arista EOS has become the operating system of choice in hyperscaler and enterprise data centers, and engineers coming from Cisco IOS will find the CLI familiar but different in the details — CIDR everywhere, port-channel instead of EtherChannel, VRRP instead of HSRP. This cheat sheet collects the configuration blocks that matter most in daily operations: secure management access, VLAN and trunk design, LACP port-channels, spanning tree, routing protocols, first-hop redundancy, and ACLs — each with a minimal, copy-paste-ready example. It is a distilled version of the CISCONET Training Solutions EOS reference, updated for current EOS releases.

Everything below is safe to run on a lab switch or in a configuration session on a production switch. Wrap changes in configure session if you want to review the diff before it lands, and keep a copy of the running configuration off-box before you start.

Management and Security Hardening

hostname switch-1
enable secret <password>
username admin privilege 15 secret <password>
management ssh
  idle-timeout 5
  no shutdown
management api http-commands
  protocol https
  no shutdown

Note that EOS names interfaces as Ethernet1/Et1 without speed, and uses the Linux filesystem for flash.

A few habits are worth enforcing from day one, because they are much harder to retrofit. Give every switch a matching DNS name and hostname so logs are searchable. Never leave the default admin account without a secret. Restrict management SSH to a management VRF or an out-of-band subnet, and disable the protocols you are not using:

management ssh
  idle-timeout 5
  no shutdown
management console
  idle-timeout 10
no management api http-commands
no lldp run
   ! re-enable per interface where LLDP is actually needed
interface Management1
  ip address 10.10.10.11/24
  no shutdown
ip route 0.0.0.0/0 10.10.10.1

For anything beyond a lab, replace local authentication with a central server so account removal is a single change rather than a fleet-wide script. EOS supports both TACACS+ and RADIUS with per-command authorisation:

aaa authentication login default group tacacs+ local
aaa authorization commands all default group tacacs+ local
tacacs-server host 10.10.20.5 key <key>
tacacs-server timeout 5

Management API, eAPI and Automation

EOS shipped a REST API before most vendors had one, and it remains the feature that most changes how a network is operated. Rather than screen-scraping SSH, enable the API and consume JSON directly:

management api http-commands
  protocol https
  no shutdown
  vrf management
management api models
  provider sysdb
  no shutdown

Once enabled, any CLI command can be issued over HTTPS and returned as structured JSON: show version, show interfaces status, show ip route and several hundred others all have native JSON equivalents. That is the foundation for configuration templates, compliance checks and telemetry pipelines, and it is the reason EOS deployments tend to automate earlier than equivalent IOS estates.

VLANs, Trunks and Port-Channels

vlan 10
  name wireless
interface Ethernet1
  switchport mode access
  switchport access vlan 10
interface Ethernet1/1
  switchport mode trunk
  switchport trunk native vlan 999
  switchport trunk allowed vlan 10-12
interface Ethernet 1-2
  switchport mode trunk
  channel-group 1 mode active
interface Port-Channel 1
  switchport mode trunk

Three details catch out engineers new to EOS. First, the native VLAN defaults to 1 and there is no DTP, so a link is either access or trunk by configuration and never negotiates. Second, channel-group mode active means LACP; mode on is a static bundle with no protocol. Third, ranges use a comma-separated list and hyphen syntax (Ethernet1-4,7) and the member interfaces inherit nothing from the port-channel, which is why the port-channel carries the Layer 3 configuration and the members carry only the bundle command.

Two hardening commands complete the picture. Restrict the allowed VLAN list on every trunk rather than allowing all, and disable unused ports so a patch cable cannot create a loop or a rogue access:

interface Ethernet1/1
  switchport trunk allowed vlan 10-12,999
interface Ethernet5-8
  shutdown
  switchport mode access
  switchport access vlan 999

Spanning Tree and Port Protection

spanning-tree mode rapid-pvst
interface Ethernet1/1
  spanning-tree portfast
  spanning-tree bpduguard enable

Rapid-PVST is the right default for an access layer that interconnects with other vendors, because it speaks the same protocol as Cisco's RSTP. Where both ends of a link are Arista, MSTP with a deliberate instance-to-VLAN mapping allows per-VLAN load sharing and avoids the single-blocked-link inefficiency of a pure PVST topology.

portfast plus bpduguard together are the correct answer for host ports: the port enters forwarding immediately, and if it ever sees a BPDU it is error-disabled rather than allowed to become a root port. Add spanning-tree loopguard default and, on links toward the distribution layer, spanning-tree guard root to make the intended topology explicit rather than accidental.

Layer 3 and Routing

OSPFv2 with a global method, or directly on an interface:

router ospf 1
  router-id 172.16.255.1
  network 192.168.0.0/16 area 0
interface Ethernet1/1
  ip ospf 1 area 0

eBGP and an SVI for inter-VLAN routing:

router bgp 65001
  neighbor 192.168.1.2 remote-as 65000
  network 192.168.1.0/24
interface vlan 10
  ip address 172.16.1.1/24
  no shutdown

The interface-level method is the one to prefer in a routed leaf-spine fabric: instead of enumerating network statements, enable the protocol where you want it and be done. Turning routing on for every port at once is a single command:

interface Ethernet1-4
  no switchport
  ip address 10.0.0.1/31
  ip ospf 1 area 0
  no shutdown

For BGP, peer groups keep the configuration short and the session behaviour consistent, and an address family lets you tune timers per neighbour without duplicating the remote-as statement. Redistribute only what you intend to advertise: the classic BGP mistake is redistributing a connected block that includes the management subnet.

First-Hop Redundancy: VRRP

interface Ethernet1/1
  ip address 172.16.1.2/24
  vrrp 1
    ip 172.16.1.3
    priority 110
    preempt

VRRP is the EOS answer to HSRP, and it interoperates with any other vendor that implements RFC 5798. The virtual address must be different from the interface address, priority above 100 makes a router the master, and preempt returns mastership as soon as the higher-priority router comes back. Lower the advertisement interval with vrrp 1 timers advertise 1 only if you have measured the failure-detection requirement — aggressive timers on a busy control plane cause false failovers.

ACLs and Monitoring

ip access-list extended HTTPS-FILTER
  permit tcp 192.168.1.0/24 host 172.33.1.1 eq 443
  deny tcp 192.168.1.0/24 any eq 23
  permit ip any any
interface Ethernet1/1
  ip access-group HTTPS-FILTER in

snmp-server community arista ro
logging host 192.168.3.1
ntp server 172.16.1.1 prefer

EOS uses pure CIDR for wildcard-free matching, so host and a prefix length replace the mask/wildcard pairs of IOS. Apply an ACL at the most specific point at which it still sees the traffic you want to filter, and always finish an extended list with an explicit deny or an explicit permit so the rule set reads unambiguously.

For production monitoring, move past SNMPv2c communities. SNMPv3 with authentication and privacy, plus a unicast syslog destination and authenticated NTP, gives you telemetry you can trust and timestamps you can correlate:

snmp-server view MONITOR iso included
snmp-server group NOC v3 priv read MONITOR
snmp-server user collector NOC v3 auth sha <auth-key> priv aes <priv-key>
logging buffered 100000
logging trap informational
logging host 192.168.3.1
ntp server 172.16.1.1 prefer
ntp server 172.16.1.2

Configuration Management: Sessions, Commit and Rollback

This is the EOS feature that IOS engineers miss most when they go back. A configuration session is a staging area: changes are validated and can be shown as a diff before anything reaches the running configuration, and a commit can be scheduled with an automatic rollback if you fail to confirm.

configure session MAINTENANCE
   interface Ethernet48
      no shutdown
   show session-config diffs
   commit timer 00:10:00
   ! verify connectivity, then
   commit

If you lose management access and never type commit again, EOS rolls the session back automatically after the timer expires. That single workflow removes most of the risk from remote change windows, and it is worth teaching to every engineer on the team before they touch a production uplink.

CLI Tips for Automation

• Pipelining: show running-config | include hostname
• Structured output: show interfaces json — perfect for eAPI/gNMI workflows.
• Verify trunking with show interfaces switchport.
• Counters without paging: show interfaces counters errors | no-more or disable paging with terminal length 0.
• Filter by regular expression: show ip route | grep "10\.0\.0\.".
• Compare configurations: show diff after loading a candidate file.

Interface Naming, Ranges and Port Profiles

EOS interface names are positional and speed-agnostic, which is a deliberate break from IOS. Ethernet1 is the first port on the faceplate; Ethernet1/1 and Ethernet1/2/1 describe line-card and sub-slot positions on modular or breakout configurations. Because the name does not encode speed, a 25G port and a 100G port are both simply Ethernet, and a breakout of one 100G port into four 25G links appears as Ethernet1/1 through Ethernet1/4 with the port number used as the lane index.

Ranges accept commas and hyphens and collapse neatly, which is what makes large-scale provisioning practical:

interface Ethernet1-4,7,10-12
   description UNUSED_ACCESS_PORTS
   switchport mode access
   switchport access vlan 999
   shutdown
show interfaces status
show interfaces Ethernet1-4 counters

A port profile is EOS's answer to Cisco's interface range macro, and it is the cleaner abstraction: define the template once, apply it to many ports, and change them all by editing the profile.

port profile ACCESS-DATA
   switchport mode access
   switchport access vlan 10
   spanning-tree portfast
   spanning-tree bpduguard enable
interface Ethernet5-24
   inherit port-profile ACCESS-DATA

Booting, Image Management and Upgrades

EOS runs from a pair of boot images on the local flash filesystem, and the Linux layer is visible through bash. That changes how upgrades and rollbacks work compared with a monolithic NOS: you stage a second image, set the boot order, and reboot, and the previous image is still on disk if the new one fails to come up.

show version
show boot-config
show flash
copy https://files.example.net/EOS-4.31.2F.swi flash:
boot system flash:EOS-4.31.2F.swi
reload
bash df -h
bash ls -al /mnt/flash

Two precautions make upgrades boring. Copy the running configuration off-box first, and verify free space on flash before staging the image. On platforms that use a shared flash partition, a failed copy can leave you with less free space than the current image needs to boot.

Verification Quick Reference

Operational Habits That Pay Off

• Version the configuration. Back it up nightly off-box; the fastest restore is always a known-good file, not a rebuild from memory.
• Keep the change window short. Use a session with a commit timer, make one logical change, verify, commit.
• Document the addressing scheme. Loopback per switch for router IDs, /31 point-to-point links, and a reserved VLAN range for transit and native VLANs.
• Test before you trust. Portfast and bpduguard on a host port is safe; the same pair on an uplink will blackhole it at the first BPDU.
• Automate the third repetition. If you have typed the same sequence three times, it belongs in a template driven through eAPI rather than in a terminal.

Related Articles

Go deeper with the Arista EOS MLAG configuration run book or the EOS upgrade via USB device walkthrough.

Adjacent topics worth reading next: the Cisco to Arista EOS command mapping cheat sheet for IOS engineers, the EOS AAA with TACACS+ and RADIUS guide for centralised authentication, and the EOS BGP peers and peer groups configuration reference.

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