Arista ACE Specialist - Data Center common mistakes
Arista ACE Specialist - Data Center · Understand the traps and how to avoid them.
Treating MLAG as a single control plane and assuming the two peers run one shared Spanning Tree or one shared routing adjacency, so the candidate mis-predicts what happens when the peer link fails.
MLAG is often mentally collapsed into 'a stacked switch' because the data plane presents one logical port-channel to downstream devices. Candidates who have only configured vendor stacks miss that each peer keeps an independent control plane, independent STP instance, and independent routing process.
What to do instead
State the rule explicitly while studying: MLAG peers synchronize LAG membership and MAC/ARP information over the peer link but do not merge control planes. Practice predicting behavior for peer-link failure versus peer-device failure separately, and verify with the recommended peer-link and orphan-port configurations.
Describing the peer link as the path that carries normal dual-homed traffic, or sizing it as a backup link only.
Diagrams show a line between the two MLAG peers, so it reads like an uplink. The actual rule is that steady-state traffic from a dual-homed host is hashed across local member links, and the peer link carries only traffic destined for the peer's members plus flooded or orphaned traffic.
What to do instead
Redraw the topology with traffic arrows for three cases: normal hashing, single-uplink failure, and peer-link failure. Size the peer link for the worst case where all dual-homed traffic must cross it.
Assuming a port-channel can be formed with a member link that is in a different VLAN or has a mismatched speed and expecting it to come up, then being unable to explain why the bundle is down.
Candidates memorize 'configure the channel-group' but not the consistency checks EOS applies to member links, so they cannot reason about partial-up or suspended-member states under LACP.
What to do instead
Learn the specific per-member requirements (speed, duplex, VLAN membership, MTU, and LACP mode agreement) and the meaning of each LACP state flag. Practice diagnosing a bundle where one member is suspended while the rest are bundled.
Reading a running-config and assuming the absence of an explicit command means the default applies, without checking the actual operational state in show output.
EOS uses defaults and default-hiding in running-config, and features such as routing, MLAG, or tap aggregation change the meaning of otherwise identical interface stanzas. Candidates answer from the config text alone.
What to do instead
For any scenario question, cross-check the config against the relevant operational command (interface status, protocol neighbor state, or feature status) before concluding what the device is doing.
Confusing the roles of CloudVision CVP, the EOS streaming telemetry agents, and eAPI, and answering questions about 'automation' with the wrong component.
All three are 'automation' in marketing material. Candidates do not separate configuration management and change control (CloudVision) from on-box programmatic access (eAPI) from state export (telemetry).
What to do instead
Build a one-line definition for each: CloudVision for fleet-wide change workflow, compliance, and visibility; eAPI for structured CLI/JSON-RPC access to a single device; telemetry for pushing state to collectors. Then map each exam scenario to exactly one of these.
Assuming a CloudVision change is applied immediately and atomically to every device, and mis-answering questions about change control, rollback, and compliance drift.
Candidates treat CloudVision like a single-device CLI session. In practice changes go through a change-control workflow with approvals, per-device task execution, and possible partial failure, and devices can drift out of compliance afterward.
What to do instead
Study the change-control lifecycle (proposed change, approval, execution, per-device task results) and the concept of compliance versus intended configuration. Practice reasoning about what happens when one device in a change fails.
Designing a Layer 2 domain that spans the whole data center and then being unable to justify the design against the exam's fault-domain and convergence criteria.
Extending VLANs everywhere is the intuitive way to keep workloads simple, and candidates carry that habit from smaller environments. The exam expects reasoning about broadcast domains, STP scope, and blast radius.
What to do instead
For any design question, state the Layer 2 boundary and the Layer 3 boundary explicitly, and justify each in terms of fault isolation and convergence. Prefer routed designs at the spine and limit Layer 2 to where it is required.
Sizing or cabling a leaf-spine fabric by oversubscription intuition alone, without checking that the chosen port counts and speeds actually close the design.
Candidates pick a topology shape that looks right and skip the arithmetic on uplink capacity, oversubscription ratio, and rack density, so the answer is plausible but does not meet the stated requirement.
What to do instead
Do the arithmetic explicitly in every design question: leaf downlinks to hosts, leaf uplinks to spines, spine port count versus number of leaves, and resulting oversubscription. Reject any option that fails the numbers even if the shape looks correct.
Troubleshooting a routing adjacency by checking interface status only and stopping when the link is up, without verifying that the neighbors agree on subnet, area or AS, timers, and authentication.
'Link up but no neighbor' is the most common real-world symptom, and candidates jump to a conclusion instead of walking the specific mismatch conditions for the protocol in question.
What to do instead
Use a fixed checklist per protocol: IP subnet and mask match, correct area or AS, matching hello/hold or dead timers, matching authentication, and MTU. Practice reading neighbor-state output to identify which item is mismatched.
Assuming ECMP will use all available equal-cost paths for a given flow, and mis-predicting the effect of a single link or spine failure on existing flows.
Candidates know ECMP 'load balances' but not that hashing is per-flow and that a topology change rehashes flows, so some flows move and some do not. They also overlook that unequal paths are not used without specific configuration.
What to do instead
Learn that ECMP selects among equal-cost next hops via a hash of flow fields, that a failure causes rehash and possible reordering, and that unequal-cost multipath is not default behavior. Practice predicting which flows are affected when one spine is removed.