County architects want each leaf to maintain fewer BGP sessions as spine count grows, without abandoning multipath. Which control-plane approach best targets session-count scaling?
Select an answer to reveal the explanation.
Short Explanation
BGP sessions are like open phone lines—every extra spine can mean another call per leaf. Route reflection (or a deliberate peer design) keeps the conversation count manageable while multipath still does the heavy lifting for packets.
Full Explanation
As spine count grows in a county fabric, each leaf’s BGP session count can climb if every leaf peers densely to every spine or peer set. Route reflection, or carefully limited peer topologies, targets that control-plane session-scaling problem: leaves obtain fabric reachability without maintaining a full mesh of control-plane relationships, while multipath can still be preserved in the data plane when paths remain equal-cost.
Requiring every leaf to open a full mesh of BGP sessions to every other leaf in addition to all spines worsens session count rather than helping. Replacing BGP with RIP version 1 on leaf-spine links is not a professional IP-fabric control plane and does not solve modern Clos scaling. Advertising only connected interfaces and never using loopbacks does not automatically drop session count and undermines stable VTEP/router-id addressing.
Exam caveat: session-count scaling is a control-plane concern distinct from RIB prefix count; RR/peer-set design answers session sprawl without implying that ECMP must be abandoned.
Operational check: document leaf BGP neighbor counts before and after introducing RRs or reduced peer sets; confirm fabric loopbacks remain reachable with multiple equal-cost next hops and that VTEP underlay pings still succeed.