A metro interconnect starts injecting large volumes of external prefixes into the city’s IP fabric underlay. What boundary practice protects fabric scale?
Select an answer to reveal the explanation.
Short Explanation
The underlay should stay a clean city map, not the entire world’s phone book. Filter at the border so metro/Internet sprawl never lands on every leaf—hand off defaults or selective aggregates instead.
Full Explanation
When a metro interconnect injects large external tables into the city’s IP fabric, the protective boundary practice is to filter at the fabric border so Internet-scale detail never becomes every leaf’s underlay diet. The DC underlay should carry fabric infrastructure and controlled reachability—defaults or selective aggregates at the edge—rather than full external tables that consume RIB/FIB and destabilize operations.
Redistributing the entire Internet table into every leaf’s underlay BGP so defaults are unnecessary deliberately creates the scale failure the stem describes. Carrying full external tables only in OSPF while keeping BGP free of them still dumps Internet-scale state into the fabric control plane by another protocol. Muting all spine interfaces during peak hours is an availability anti-pattern, not a routing-boundary design.
Exam caveat: border filtering and defaults/aggregates are the expected scale hygiene; protocol shopping (BGP versus OSPF) is not a substitute for refusing full tables in the DC underlay.
Operational check: on border leaves/spines, verify import policy rejects or aggregates external sprawl; confirm interior leaves show defaults or selective prefixes only, with stable underlay to VTEP loopbacks.