City hall discovers finance routes appearing inside the public-kiosk VRF after a change. What does that symptom most clearly indicate about VRF design?
Select an answer to reveal the explanation.
Short Explanation
If finance routes appear in your kiosk VRF, think of two route books that should stay separate but have started sharing pages. You’re seeing a route-separation failure—an unintended leak or shared global table behavior—not a change caused by GRE keepalives, VXLAN VNIs automatically sharing routes, or hypervisor MAC tables.
Full Explanation
When finance routes appear inside the public-kiosk VRF after a change, route separation has failed: VRFs are intended to maintain independent routing tables, so finance prefixes in the kiosk table indicate an unintended inter-VRF leak, an import/export misconfiguration, or shared global-table behavior. In a multi-tenant edge design, this is a control-plane isolation break, not a cosmetic display quirk. GRE keepalives monitor tunnel liveliness; they do not replace VRF route distinguishers or determine VRF identity. VXLAN VNIs do not automatically put every tenant VRF in one shared routing table or import all routes into every VRF; VNI-to-VRF binding and route exchange require deliberate configuration. Type 1 hypervisors do not flatten VRFs into one MAC table on an edge router; hypervisor type and MAC learning do not explain finance prefixes in the kiosk routing table. Exam caveat: a foreign prefix may be present because of an intentional, scoped leak, so its presence alone does not prove an accident; verify the intended policy. Practical check: compare the kiosk and finance VRF route tables, inspect route-target import/export settings and any redistribution or route-leak statements changed during the maintenance window, remove unintended imports, and confirm the finance prefixes no longer appear in the kiosk VRF.