I85PREP
⌘ K
Arista Foundations study materials
Arista Foundations study resources

EVPN Route-Type 2 Scale in a Multi-Pod Fabric

Arista Foundations · Put your knowledge to work in context.

All case studies

EVPN Route-Type 2 Scale in a Multi-Pod Fabric

A service provider runs an Arista EVPN-VXLAN fabric with two pods connected by a super-spine. Each pod has 48 leaves and 4 spines; there are 6,000 tenant MAC addresses per pod and 1,200 /32 host routes. The CloudVision server manages 104 switches. After a maintenance window, operators report that CloudVision's device inventory shows 11 switches in an 'unreachable' state and the topology view is stale for one pod. At the same time, EVPN convergence after a spine reload took 40 seconds, longer than the 15-second target. The team suspects both problems share a root cause and wants to know where to look first and how to separate the two issues.

1. How would you separate the CloudVision reachability problem from the EVPN convergence problem, and what shared-cause hypotheses are worth testing first?

Read the worked answer

Separate by plane. CloudVision reachability is a management-plane question: can the CloudVision cluster reach each switch's eAPI/TerminAttr/SSH endpoint, and is the switch's management VRF and AAA healthy? EVPN convergence is a data-plane/control-plane question inside the fabric. They can share a cause if the management network rides the same underlay or if a spine reload also disrupted the management path to the affected pod.

Test in this order:

  1. Confirm whether the 11 unreachable switches are all in the stale pod. If yes, a pod-level management path or super-spine reachability issue is likely, not 11 independent switch faults.
  2. From the CloudVision node, ping and curl the eAPI of one affected switch; check show management api and AAA on the switch.
  3. Check whether the spine reload affected the management VRF or the route to the CloudVision cluster.
  4. For EVPN, check BGP EVPN session state and route-type 2/5 counts on the affected leaves, and time the BGP best-path and VXLAN FDB reprogramming separately.

Do not assume a single root cause until the 11 switches are confirmed to be pod-correlated.

2. The 40-second EVPN convergence is traced to route-type 2 withdrawal and re-advertisement for 6,000 MACs. What design and tuning levers would you evaluate to reach the 15-second target?

Read the worked answer

First, confirm the measurement: is the 40 seconds BGP convergence, or is it ARP/MAC re-learning after the spine returns? Those have different levers.

Levers to evaluate:

  • BGP timers and graceful restart: ensure GR/LLGR is configured so a spine reload does not force full withdrawal; tune hold-time and advertisement interval within vendor guidance.
  • Route-type 2 suppression / MAC mobility dampening: excessive MAC moves can cause churn. Check for flapping hosts or misconfigured anycast gateways causing MAC mobility events.
  • EVPN multihoming (ESI): if leaves are dual-homed, ESI reduces the number of independent MAC advertisements and improves convergence.
  • Scale and hardware: 6,000 MACs and 1,200 host routes are modest; if convergence is slow, check control-plane CPU, FDB programming rate, and whether the spine is doing more work than expected.
  • Underlay stability: a spine reload should not flap the underlay; check BGP/OSPF timers and BFD.

Judgement: measure first, then tune. Blindly lowering BGP timers can increase churn and CPU load at this scale.

3. CloudVision shows 11 switches unreachable but the fabric is passing traffic. What is the operational risk, and how do you prioritize remediation?

Read the worked answer

The risk is loss of visibility and automation, not immediate forwarding failure. If CloudVision cannot reach 11 switches, change control, compliance checks, and config backup are degraded, and any automated remediation may be blind to those devices. Traffic still flows because the data plane is independent of the management plane.

Prioritize by blast radius and criticality:

  1. Identify whether the 11 are in one pod; if so, treat it as one management-path incident, not 11 device incidents.
  2. Restore management reachability for the most critical devices first (super-spines, then pod spines, then leaves).
  3. Verify the switches are healthy via local CLI while CloudVision is out, so you are not blind.
  4. After restoration, reconcile CloudVision inventory and topology, and confirm no config drift occurred during the blind window.

The judgement is to treat this as a management-plane incident with a bounded blast radius, and to avoid making unrelated fabric changes until visibility is restored.