Overlay /32 host routes from EVPN are exploding on county leaves and stressing RIB and FIB, even though the underlay still has only a modest number of loopbacks and fabric links. What distinction should engineers make when diagnosing the scale problem?
Select an answer to reveal the explanation.
Short Explanation
Underlay routes are the street map; overlay host routes are every house number glued onto that map. When the house-number list blows up, that is an overlay scale issue—do not confuse it with a skinny underlay that still only has a handful of fabric prefixes.
Full Explanation
County leaves can show a healthy, modest underlay—loopbacks and fabric links—while EVPN overlay /32 host routes explode in the same RIB/FIB. Those are separate scale problems. Overlay host-route growth needs overlay-specific controls such as aggregation strategy, routing model (where /32s are originated), route-target scoping, and host-route policy. Treating the symptom as “the underlay is too small” misdirects remediation when infrastructure prefixes are already bounded.
Claiming underlay infrastructure-route scale and overlay host-route scale are the same limit that always share one TCAM pool identically oversimplifies platforms and blurs the diagnostic split the stem requires. Shrinking MTU on spine links does not remove overlay host routes from leaf FIBs. Disabling BGP on the spines is not a preferred way to compress overlay host-route tables and would harm underlay reachability.
Exam caveat: distinguish underlay prefix scale from EVPN/VXLAN host-route scale; many exam traps conflate the two when only overlay /32s are growing.
Operational check: count underlay infrastructure prefixes versus EVPN host routes on stressed leaves; apply overlay route controls or aggregation in a lab VNI and re-measure FIB occupancy without changing underlay loopback design.