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-route-reflector models can build a civic Clos underlay, but their operational scaling profiles differ. Unique ASN-per-leaf designs often accumulate ASN inventories, leaf-specific import/export objects, and policy exceptions as pods expand—exactly the sprawl drowning the city’s operators. An IBGP fabric with route reflectors keeps a common AS and centralizes reflection, which can reduce ASN and policy object growth while still advertising loopbacks for VTEP reachability when configured correctly.
Claiming EBGP-per-leaf always uses fewer total sessions than IBGP with RRs is not generally true and misses the policy/ASN operational issue. Saying IBGP with route reflectors cannot advertise loopbacks needed for VTEP reachability is false—loopbacks are routinely carried in IBGP underlays. Asserting that only EBGP fabrics support ECMP so IBGP-plus-RR cannot scale bandwidth confuses multipath capability with AS design; IBGP multipath is available when enabled appropriately.
Exam caveat: JN0-683 may ask you to weigh operational tradeoffs rather than declare one underlay BGP model universally illegal; highlight ASN/policy sprawl versus RR operational centralization.
Operational check: inventory unique ASNs and per-leaf policy objects in the EBGP design, compare session and RR topology for an IBGP alternative, and validate that VTEP loopbacks still appear in the RIB with multipath toward spines under the chosen model.