Telemetry flags rising CRC errors on one civic fabric optic between leaf and spine. How should that finding rank in IP fabric troubleshooting?
Select an answer to reveal the explanation.
Short Explanation
CRC errors on a fabric optic are the check-engine light for that lane—intermittent drops and weird ECMP hash pain often start there. Pull the physical path to the front of the queue instead of blaming EVPN first.
Full Explanation
Rising CRC errors on one civic fabric optic between leaf and spine should be treated as a high-priority physical root-cause class for intermittent loss and ECMP imbalance. Soft errors and dirty fiber can drop or corrupt a subset of hashed flows while BGP remains Established between flaps, producing application symptoms that look like overlay instability until someone reads the interface error counters on that specific leaf-spine lane.
Ignoring CRC counters until BGP drops Established is wrong—optics affect forwarding while sessions stay up. Clearing CRC counters daily as routine hygiene without inspecting the optic or cable destroys forensic evidence and fixes nothing. Attributing CRC spikes to EVPN route-type churn and dampening Type-2 imports first mis-orders root-cause analysis toward the control plane when the physical path is sick.
Exam caveat: physical/CRC faults on fabric links belong ahead of overlay dampening in professional troubleshooting order for municipal Clos fabrics.
Operational check: identify the CRC-rising interface, inspect/clean/replace the optic and fiber path, clear counters only after repair, and confirm loss metrics and ECMP balance recover before changing any EVPN import or damping policy.