A metro design assigns different VNIs to Parks, Utilities, and Public Safety departments. How should architects treat those VNIs in the VXLAN control plane?
Select an answer to reveal the explanation.
Short Explanation
Different VNIs are different neighborhoods in the overlay phone book—Parks traffic should not share Utilities’ flood domain just because they share spines. EVPN and the VXLAN header both key on that VNI identity. Sharing an ASN in the underlay does not glue those broadcast domains together.
Full Explanation
When a metro design assigns different VNIs to Parks, Utilities, and Public Safety, architects should treat each VNI as a distinct overlay segment identity in both control-plane advertisements and data-plane encapsulation, keeping department broadcast domains separated when VLAN-to-VNI mapping and route-target policy are correct. Per-department VNIs are a standard Layer-2 overlay segmentation pattern for municipal multitenancy.
All departments must not share one VNI merely so EVPN can advertise a single combined MAC table—that collapses isolation the design requires. VNIs are not cosmetic labels that never appear in EVPN attributes or VXLAN headers. Different VNIs do not merge into one broadcast domain as soon as leaves share an underlay ASN.
Exam caveat: VNI equals the overlay segment boundary; underlay ASN commonality does not merge VNIs or L2 domains on the exam.
Operational check: place a test host in each department VNI, confirm EVPN MAC routes reflect the correct VNI and route-target context, and verify Parks cannot flood or learn into Public Safety’s bridge domain across the metro fabric.
In civic fabric operations, retain the correct idea—Each VNI is a distinct overlay segment identity in control-plane advertisements and data-plane encapsulation, keeping department broadcast domains separated when mapped correctly—and reject distractors that confuse layers or tools. Specifically, do not treat “All departments must share one VNI so EVPN can advertise a single combined MAC table only.” as valid, do not accept “VNIs are cosmetic labels and never appear in EVPN route attributes or VXLAN headers.” as a substitute design, and do not operationalize “Different VNIs merge into one broadcast domain as soon as leaves share an underlay ASN.” in production runbooks. Re-validate after changes with show commands for sessions, routes, VTEP reachability, and a simple tenant traffic test appropriate to the VNI under review.