A civic EBGP-per-leaf fabric is drowning operators in unique ASNs and per-leaf policy objects as pods expand. What operational scaling tradeoff should the design review highlight versus an IBGP-plus-route-reflector underlay?
Select an answer to reveal the explanation.
Short Explanation
Unique ASN-per-leaf is like issuing every desk its own zip code—workable until the city has hundreds of desks and the policy binders explode. IBGP with route reflectors keeps one AS and centralizes reflection, trading some EBGP simplicity for less ASN/policy sprawl.
Full Explanation
Both EBGP-per-leaf and IBGP-with-RR models can build Clos underlays, but their operational scaling profiles differ. Per-leaf ASN designs often accumulate ASN assignments and leaf-specific policy as the fabric grows. An IBGP fabric with route reflectors reduces ASN sprawl and can centralize reflection, while still advertising loopbacks for VTEP reachability and supporting multipath when configured correctly. Claiming EBGP always has fewer sessions, that IBGP cannot advertise loopbacks, or that only EBGP supports ECMP is incorrect.