Arista Foundations common mistakes
Arista Foundations · Understand the traps and how to avoid them.
Treating MLAG as a single control-plane switch and expecting both peers to run independent spanning-tree and routing adjacencies toward attached hosts.
Candidates conflate MLAG (a multi-chassis LAG with a shared logical view for L2 forwarding) with a true stacking or single-management-plane technology, so they assume one shared configuration and one shared control plane.
What to do instead
State explicitly that each MLAG peer keeps its own independent control plane (separate STP instances coordinated via the peer link, separate routing processes) while presenting a single logical LAG to the host; verify by describing what happens to the peer link failure and to a single-peer reload.
Assuming EOS runs a single monolithic routing protocol process and that BGP, OSPF, and IS-IS share one RIB with identical administrative-distance behavior across all address families.
Candidates carry over assumptions from single-binary network OSes and from vendor-neutral study material, then mispredict which route wins when multiple protocols are present.
What to do instead
Learn EOS's multi-agent architecture (separate protocol agents feeding a central RIB manager) and the default administrative distances per protocol and address family; practice predicting the installed route when a static, OSPF, and eBGP path to the same prefix coexist.
Designing a leaf-spine fabric with oversubscription and ECMP assumptions based on link count only, ignoring that hash polarization can leave some spine links underused for a given flow set.
Candidates memorize 'ECMP gives you N-way load balancing' and treat the fabric as perfectly balanced, missing that per-flow hashing and flow sizes determine actual utilization.
What to do instead
Explain hash polarization and the role of flow entropy (5-tuple) and hash-seed variation across leaves; describe why many small flows balance better than few large flows and how to verify balance with per-interface counters rather than assuming even distribution.
Treating CloudVision as a device-by-device configuration tool and expecting changes to be pushed immediately to each switch without a change-control workflow.
Candidates map CloudVision onto a familiar CLI-in-a-GUI model and miss the change-control (review, approve, execute) model and the separation between the telemetry/visibility plane and the configuration plane.
What to do instead
Describe the CloudVision workflow end to end: change is built as a change control, reviewed, approved, then executed, with per-device results and rollback; distinguish streaming telemetry/state visibility from configuration management.
Confusing underlay and overlay responsibilities, e.g. expecting the underlay IGP/BGP to carry tenant MAC addresses or expecting VXLAN to provide the loopback reachability it actually depends on.
Candidates learn VXLAN and routing as separate topics and never build a layered mental model, so they misassign functions when asked 'which protocol does X'.
What to do instead
Draw the two layers explicitly: underlay provides IP reachability between VTEP loopbacks (routed, ECMP); overlay (VXLAN with EVPN control plane) carries tenant L2/L3. Test yourself by classifying each function (MAC learning, loopback reachability, multitenancy, VTEP discovery) to the correct layer.
Answering EVPN questions by describing flood-and-learn VXLAN behavior, such as expecting unknown unicast to be flooded to all VTEPs in a properly designed EVPN fabric.
Candidates study VXLAN data-plane flooding first and never update their model when EVPN's control plane (MAC/IP advertisement, IMET routes) is introduced.
What to do instead
State that EVPN advertises MAC/IP reachability via BGP so the data plane can forward without flooding, and describe the role of the IMET (inclusive multicast Ethernet tag) route for BUM traffic and of ARP/ND suppression to reduce flooding.
Assuming all switch ports are trusted for QoS markings and that DSCP is preserved end to end without configuration.
Candidates treat QoS as a single global setting and forget that trust boundaries, per-port trust states, and egress queue mapping must each be configured and verified.
What to do instead
Describe the trust boundary explicitly (which ports trust DSCP/CoS, which re-mark), how internal traffic classes map to egress queues, and how to verify with per-queue counters; note that a misconfigured trust state silently collapses classes.
Reading sFlow/telemetry counters as flow-accurate and concluding a host is not sending traffic when sampled data shows nothing.
Candidates treat sampled telemetry as a packet capture and forget the sampling rate and the probabilistic nature of sFlow, leading to wrong root-cause conclusions during troubleshooting scenarios.
What to do instead
State the sampling interval and explain that low-rate or short-lived flows can be missed entirely; pair sampled telemetry with interface counters and, where available, flow-level or tap-based data before drawing conclusions.
Applying a control-plane ACL or CoPP policy and expecting data-plane traffic to be filtered, or vice versa.
Candidates conflate 'protect the CPU' with 'filter user traffic' because both use ACL syntax and both live in the security domain.
What to do instead
Separate the two planes clearly: CoPP/control-plane ACLs protect the switch CPU and affect only punted traffic; interface ACLs filter transit data. Verify by describing which traffic is punted to CPU (routing protocols, management, TTL-expired, ARP) versus forwarded in hardware.
Assuming a routed leaf-spine fabric needs no spanning tree at all, then failing to explain what happens on a leaf pair with MLAG-attached dual-homed hosts or orphan ports.
Candidates learn 'routed fabric = no STP' as a slogan and do not account for L2 segments that still exist at the leaf edge, including MLAG peer links and single-homed orphan devices.
What to do instead
Qualify the claim: the spine layer is fully routed with no L2 loops, but leaf-edge L2 domains still run STP (or an equivalent loop-prevention mechanism) for dual-homed and orphan ports. Describe the specific failure that STP prevents on a leaf pair and how MLAG interacts with it.