EOS foundations and first configuration

What you will learn. This course now targets Arista Data Center Engineering Specialist preparation. You will build a small fabric, explain its dependencies, diagnose faults and collect evidence that the intended service works. Bring IPv4 subnetting, basic routing and switching knowledge. If those are unfamiliar, complete the networking foundations material first. Think of this course as a driving school: a practice simulator develops habits, while supervised practice in the actual vehicle establishes abilities the simulator cannot measure.

Use three evidence levels

Explain means you can describe why a feature exists and predict the result of a change. Simulate means you can build and repair the supported feature in CONFIG without copying the solution. Validate on platform means you repeat the task on an authorized EOS and CloudVision practice environment and save observed results. These are different accomplishments. A correct multiple-choice answer cannot substitute for operating a fabric, and a green simulator task does not establish real-platform proficiency.

Your module route

1. EOS foundations: navigate modes, identify interfaces, capture a baseline, stage a change and save verified state.
2. Switching, LACP and MLAG: build VLAN and gateway connectivity, aggregate links, understand failure domains and test dual-homed attachment.
3. Underlay: establish routed links and loopback reachability, then investigate route propagation and alternate paths.
4. VXLAN and EVPN: distinguish transport from tenant service, map segments, check control-plane information and prove endpoint traffic.
5. Operations: use structured evidence, then complete the CloudVision workflow and practical assessment runbooks.

Keep the advanced chapters with their parent module. The EVPN extension follows the existing L2 exercises; the CloudVision extension follows the local change-control exercises. When a later chapter exposes a weak prerequisite, return to that lab and explain its failure without using its solution. This deliberate loop is more valuable than completing every chapter once at speed.

What the 24 executable labs actually establish

The existing CONFIG lab set covers initial EOS-style configuration, VLAN/trunk/SVI work, LACP, MLAG, basic OSPF and eBGP reachability, static VXLAN, two-peer L2 EVPN and a limited eAPI/configuration-session model. It is original educational software, not an installed EOS image. Preserve the lab evidence, but do not infer unsupported functionality from commands that resemble a production switch. The simulator's labels, timings and modelled outputs are learning aids.

The additional certification chapters provide real-platform runbooks for deeper routing validation, gateway resilience, MTU, tenant VRFs, symmetric/asymmetric IRB, EVPN multihoming and CloudVision. These runbooks are not new executable simulator labs. Use an existing authorized Academy or personal lab, check its software and feature support, and obtain approval before creating paid resources. No external lab is started by reading this course.

Practice for execution, not recall alone

For each topic, first perform the task with explanations and documentation. Repeat it from a clean baseline with only your own checklist. Finally have a peer choose one fault without telling you which one, or choose a fault card before resetting the lab. Record the first evidence that isolates the fault and how you verified the repair. Work on documentation navigation as well as commands: bookmark the relevant manual sections and know what a command proves before you run it.

The practical question is: what must be true before this feature can carry the intended service? Read the configuration as a set of dependencies, then test each dependency with observed state. EOS separates protocol agents and forwarding state; Linux is the underlying operating environment, but a Linux shell and the EOS network CLI serve different jobs. Sysdb distributes state between agents. A protocol process restart and a switch reboot have very different operational impact.

Worked configuration

Apply the example only to the named lab device and substitute the peer addresses from the topology. Indentation identifies configuration context. Enter privileged mode and configure terminal before configuration examples; use end before verification commands. Record the baseline before changing a live service.

show version
show interfaces status
show running-config

Evidence to collect

Model, software release, hostname and interface inventory establish the device you are actually changing. Use the matching exercise to build the feature and inspect the resulting state. A completion task checks simulator state or real packet reachability rather than merely searching for a pasted command. When a test fails, identify the first broken dependency and repair that item. Avoid changing several unrelated settings at once, because that hides the cause and makes rollback harder.

Arista documentation · further reading

The practical question is: what must be true before this feature can carry the intended service? Read the configuration as a set of dependencies, then test each dependency with observed state. Ethernet1 is a physical EOS port, Port-Channel1 is a logical bundle, Vlan10 is a switched virtual interface and Loopback0 is a logical routed endpoint. A physical uplink configured with no switchport carries IP rather than an 802.1Q access VLAN. A loopback needs a route advertisement to be useful beyond the local switch.

Worked configuration

Apply the example only to the named lab device and substitute the peer addresses from the topology. Indentation identifies configuration context. Enter privileged mode and configure terminal before configuration examples; use end before verification commands. Record the baseline before changing a live service.

configure terminal
interface Ethernet1
 no switchport
 ip address 10.0.0.1/30
 no shutdown
interface Loopback0
 ip address 10.255.0.1/32
end
show ip route

Evidence to collect

Look for a connected underlay subnet and a local loopback route. Check the peer subnet and prefix length independently. Use the matching exercise to build the feature and inspect the resulting state. A completion task checks simulator state or real packet reachability rather than merely searching for a pasted command. When a test fails, identify the first broken dependency and repair that item. Avoid changing several unrelated settings at once, because that hides the cause and makes rollback harder.

Arista documentation · further reading

The practical question is: what must be true before this feature can carry the intended service? Read the configuration as a set of dependencies, then test each dependency with observed state. Running configuration is the current operating intent. Startup configuration is the saved configuration used for a subsequent boot. A successful copy operation is evidence of persistence, not evidence that traffic works. The correct order is inspect, change, verify traffic, then save.

Worked configuration

Apply the example only to the named lab device and substitute the peer addresses from the topology. Indentation identifies configuration context. Enter privileged mode and configure terminal before configuration examples; use end before verification commands. Record the baseline before changing a live service.

show running-config
show interfaces status
ping 10.255.0.2
copy running-config startup-config
show startup-config

Evidence to collect

Compare the intended interface and routing changes with the saved state, and record the traffic result. Use the matching exercise to build the feature and inspect the resulting state. A completion task checks simulator state or real packet reachability rather than merely searching for a pasted command. When a test fails, identify the first broken dependency and repair that item. Avoid changing several unrelated settings at once, because that hides the cause and makes rollback harder.

Arista documentation · further reading

The practical question is: what must be true before this feature can carry the intended service? Read the configuration as a set of dependencies, then test each dependency with observed state. A named configuration session stages a candidate rather than changing running state immediately. Review the candidate and commit it only when the intended changes are clear. Abort discards an uncommitted candidate. Real EOS supports additional session and rollback features; the course simulator models basic commit and abort only.

Worked configuration

Apply the example only to the named lab device and substitute the peer addresses from the topology. Indentation identifies configuration context. Enter privileged mode and configure terminal before configuration examples; use end before verification commands. Record the baseline before changing a live service.

configure session RACKCHANGE
hostname APPROVED-LEAF
interface Ethernet5
 description APPROVED
show session-config
commit
show configuration sessions

Evidence to collect

Before commit, the live hostname should remain unchanged. After commit, inspect the changed interface and save separately. Use the matching exercise to build the feature and inspect the resulting state. A completion task checks simulator state or real packet reachability rather than merely searching for a pasted command. When a test fails, identify the first broken dependency and repair that item. Avoid changing several unrelated settings at once, because that hides the cause and makes rollback harder.

Arista documentation · further reading