Municipal ops says two VRFs are “stitched” because a static route leaks prefixes between them on a border router. For JNCIP-DC DCI concepts, how should that claim be corrected?
Select an answer to reveal the explanation.
Short Explanation
Leaking routes between VRFs is like unlocking a door between two offices in the same building. Stitching overlays is more like linking two whole campuses that speak VXLAN/EVPN on each side. Related idea—traffic can meet—but not the same DCI concept.
Full Explanation
For JNCIP-DC DCI concepts, municipal ops should correct the claim: ordinary VRF route leaking on a border is related to but not the same as overlay stitching. Overlay stitching joins L2/L3 EVPN-VXLAN domains at a DCI border so multi-site fabrics exchange EVPN membership and encapsulate across sites; classic IP leaking between VRFs only injects prefixes between routing tables without defining that DCI overlay join. Calling any IP route between VRFs “EVPN stitching” erases the distinction between control-plane route leak hygiene and EVPN-VXLAN domain interconnection. Saying stitching always means only Type-5 routes and that leaking prefixes is identical to an L2 VNI stitch confuses L3 prefix interconnect with L2 stretch semantics and blast radius. Claiming VRF leaking and overlay stitching are the same control plane because both move packets between tenants conflates data-plane possibility with the EVPN-VXLAN stitch model the exam expects. Exam caveat: route leaking can be a tool inside a design, but “stitching” in DCI context refers to joining overlay domains—not every inter-VRF static. Operational check: document whether the civic border is leaking IPv4/IPv6 prefixes between VRFs, stitching EVPN VNIs/MAC-VRFs, or both; then verify with show commands that EVPN routes and VXLAN encapsulation exist when overlay stitch is intended, versus only RIB leaks when pure VRF leak was intended. Keep the municipal change ticket language precise so auditors do not treat every leak as a DCI stitch.