NOC validates municipal EVPN-VXLAN DCI after a change window. Which checklist best confirms both planes are healthy?
Select an answer to reveal the explanation.
Short Explanation
A real DCI health check is a three-part handshake: BGP EVPN talking, the right routes showing up, and VXLAN actually carrying packets. Checking spine CPU or random LLDP alone is theater. Validate control plane and data plane together.
Full Explanation
After a municipal change window, the NOC best confirms EVPN-VXLAN DCI health when EVPN sessions are up, intended Type-5 (or Type-2) routes are exchanging, and VXLAN encapsulation/decapsulation works across sites. That three-part checklist exercises both the control plane and the data plane for the civic interconnect rather than trusting a single cosmetic metric that can stay green during an overlay outage. Checking only that spine CPU is below 10 percent while ignoring EVPN and VXLAN state can green-light a broken multi-site fabric because underlay processors may be idle while borders fail to signal or encapsulate tenant traffic. Confirming only that LLDP neighbors exist on access ports in each DC proves local cabling awareness inside a room, not multi-site EVPN membership, route-target correctness, or VXLAN forwarding between cities. Verifying only that ZTP completed last month on an unrelated leaf says nothing about the interconnect just changed and conflates day-0 provisioning history with day-2 DCI validation. Exam caveat: DCI validation equals sessions plus intended routes plus encapsulation—CPU, LLDP, and ZTP are not substitutes for those three signals. Operational check: script a post-window checklist for the municipal borders that requires BGP EVPN Established, verified Type-2/Type-5 counts for critical civic tenants, successful VTEP ping, and a synthetic cross-site flow with a UDP 4789 capture; keep all artifacts in the NOC evidence folder before closing the change.