EOS and Cloud Networking Fundamentals
What to know
Arista EOS (Extensible Operating System) is a single-image, Linux-based network OS built around a shared state database (SysDB) that decouples protocol agents from the forwarding plane. Candidates should understand: the modular architecture (protocol agents publish to SysDB; processes subscribe rather than talk to each other directly), the difference between the control plane and data plane, and how EOS supports in-service software upgrades and rollback via a single image. Know the CLI model: configuration modes, running-config vs startup-config, and that changes are staged then applied.
On the cloud side, understand underlay vs overlay, VXLAN encapsulation (MAC-in-UDP, 8-byte header plus original frame), VTEPs, and the role of EVPN as the control plane for VXLAN. Know why overlays decouple the virtual topology from the physical fabric and how MTU must grow to accommodate encapsulation overhead.
Traps
- Confusing the control plane (routing/protocol decisions) with the data plane (forwarding). Questions often describe a symptom and ask which plane is at fault.
- Assuming VXLAN itself provides control-plane learning; in modern designs EVPN does, and flood-and-learn is the legacy alternative.
- Forgetting that encapsulation overhead reduces usable payload MTU; count the outer headers.
Worked example / rule of thumb
A host sends a 1500-byte frame over a VXLAN overlay. VXLAN adds 50 bytes of outer overhead (outer Ethernet 14 + IP 20 + UDP 8 + VXLAN 8). The underlay must carry at least 1550 bytes, so set fabric MTU to 1550+ (commonly 9214 for jumbo). Rule of thumb: overlay MTU = underlay MTU minus encapsulation overhead.