A county IP fabric’s leaf RIBs keep filling with host and external prefixes that servers never need for east-west reachability. What scaling practice should the fabric team apply first?
Select an answer to reveal the explanation.
Short Explanation
Picture each leaf’s route table like a filing cabinet that somebody stuffed with every flyer from the mailroom. Summarize and filter so leaves only keep what the Clos actually needs for reachability—otherwise the drawers jam as the county grows.
Full Explanation
For a county Clos, leaf RIB/FIB scale is governed by prefix discipline: advertise and retain infrastructure and necessary tenant reachability, and summarize or filter everything else at fabric borders and export points. East-west server traffic rarely needs host-level Internet tables or redundant external detail on every leaf. Summarization and import/export filtering keep silicon and BGP state within what the pod was sized for while still providing the routes the fabric truly needs.
Flooding every Internet full table onto every leaf so defaults are never required is the opposite of fabric scale hygiene and will exhaust TCAM and operations. Disabling ECMP on leaf-to-spine links does not shrink prefix count; it removes multipath resiliency without curing RIB bloat. Replacing BGP with a static mesh between every leaf pair trades controlled dynamic routing for unmanageable static sprawl and does not solve external-prefix pollution.
Exam caveat: JN0-683 expects you to separate underlay infrastructure prefixes from optional overlay or external tables and to treat summarization/filtering as a first-class scale control—not as optional polish after the Clos is live.
Operational check: on representative county leaves, compare RIB/FIB sizes before and after border filters or aggregates; confirm east-west reachability with only the retained prefixes, and verify spines still show healthy multipath next hops for fabric loopbacks.