Operations asks why the city should use GBP instead of creating a separate VNI for every application tier that needs isolation. What advantage should be emphasized?
Select an answer to reveal the explanation.
Short Explanation
VNIs are whole apartments; GBP is locks on the interior doors. You can keep one apartment and still stop the cameras from wandering into finance. Spinning a new VNI for every tier is how fabrics drown in overlay sprawl.
Full Explanation
When operations asks why the city should use GBP instead of creating a separate VNI for every application tier that needs isolation, the advantage to emphasize is that GBP enables group policy within or across groups without exploding VNI count for every tier. Microsegmentation intents such as web-to-app or app-to-database controls can live as group relationships inside fewer overlays, reducing EVPN state, bridge-domain sprawl, and day-two change burden for municipal operators. Separate VNIs are not always preferred because GBP cannot enforce any east-west controls; GBP exists specifically to enforce those controls with group identity. GBP also does not eliminate the need for EVPN entirely once groups are defined; it operates in an EVPN-VXLAN policy context rather than replacing the control plane. One VNI per host is not mandatory before GBP tags can be assigned; that prerequisite invents unnecessary overlay fragmentation. Exam caveat: prefer GBP for fine-grained east-west intent when VNI-per-tier sprawl would dominate civic operations. Operational check: compare a design with one VNI per tier against a GBP design with a small VNI set, count bridge-domains and policy objects, then validate that GBP inter-group rules meet the same isolation intent with fewer overlays in a lab leaf pair.