Compared with maintaining traditional per-IP or per-port ACL sprawl on every leaf, what operational benefit does GBP microsegmentation provide for the municipal fabric?
Select an answer to reveal the explanation.
Short Explanation
Chasing every IP with a new ACL line is whack-a-mole. GBP says “cameras” and “finance” once, then endpoints inherit the club rules as they move. That is how policy stays sane at fabric scale.
Full Explanation
Compared with maintaining traditional per-IP or per-port ACL sprawl on every leaf, the operational benefit GBP microsegmentation provides for the municipal fabric is that GBP scales policy by groups rather than endless per-IP ACL entries as endpoints move. Allow and deny intent is written once per group relationship and follows the endpoint via its group membership when servers attach on different leaves, reducing rewrite churn for city operators. GBP does not require more unique ACLs than one rule per endpoint IP; that claim inverts the scaling argument. GBP also does not eliminate all need for change control because tags never affect forwarding—group changes are forwarding-relevant and still need governance. GBP is not limited to north-south Internet edges and never east-west; its primary civic value is often east-west control inside the EVPN-VXLAN fabric. Exam caveat: contrast group-scaled policy with host-specific ACL sprawl when questions ask for the operational benefit of GBP. Operational check: migrate a lab application tier from per-IP leaf ACLs to GBP groups, move an endpoint between leaves, confirm policy still applies without rewriting host ACLs on the new leaf, and record the reduction in policy objects for the operations runbook.