A port authority’s operators struggle to reason about routing tables and policy after dozens of near-duplicate Virtual Networks were created. What VN design hygiene should leadership enforce?
Select an answer to reveal the explanation.
Short Explanation
VNs are powerful walls, but building a new wall for every closet turns the campus into a maze nobody can navigate. Keep VNs tied to real macro boundaries—OT versus office, agencies that must stay apart—not vanity duplicates. Operable routing tables beat impressive VN counts.
Full Explanation
When a port authority’s operators struggle to reason about routing tables and policy after dozens of near-duplicate Virtual Networks, leadership should limit VN sprawl by aligning VNs to genuine macro-segmentation boundaries so routing and policy remain operable. VNs are expensive cognitive and operational objects; create them for real trust/tenancy boundaries, not convenience copies.
Creating a new VN for every switch stack to guarantee underlay symmetry misunderstands underlay versus overlay and explodes scale.
Merging all municipal apps into a single VN and abandoning SGTs entirely swings to the opposite extreme and loses micro-segmentation.
Duplicating every VN into IPv4-only and IPv6-only copies regardless of traffic needs doubles sprawl without necessity.
Exam caveat: shared-services VNs and carefully planned fusion are preferable to copying an entire VN per minor department rename.
Operational check: inventory existing VNs, merge near-duplicates where policy allows, and republish a VN charter tied to trust boundaries. Present the reduced VN list at the port authority architecture board. In municipal operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the platform code and policy revisions used by the civic network team.