After a cabling change, one municipal spine carries no production traffic while peers are busy. What should engineers verify first on the leaf-spine fabric links?
Select an answer to reveal the explanation.
Short Explanation
If one spine is a ghost town after a recable, start with the boring stuff: is the L3 link up and is BGP (or the underlay IGP) actually adjacent? Dark optics and dead sessions move zero packets.
Full Explanation
After a cabling change, a municipal spine that carries no production traffic while peers are busy should push engineers to verify Layer 3 interface state and routing adjacency or BGP session health on the links toward that spine first. Dark optics, administratively down interfaces, wrong IPv4/IPv6 addressing, or missing underlay sessions move zero packets—no amount of overlay theory restores load to a spine the leaves cannot actually reach through the fabric underlay.
Asking whether EVPN Type-5 routes alone determine underlay forwarding to that spine jumps to overlay route types before proving basic underlay adjacency. Matching serial console baud rates between leaf and spine does not restore fabric traffic share. Checking whether documentation search tools index the spine hostname is unrelated to forwarding health on leaf-spine links.
Exam caveat: uneven spine load after a recable is a physical and underlay-session problem until proven otherwise; do not start with EVPN Type-5 speculation.
Operational check: from multiple leaves, show interface status and BGP/IGP sessions toward the quiet spine; restore any down or miswired links; confirm ECMP next hops return and interface counters show production traffic rebalancing onto that spine.