A municipal pod is approaching hardware TCAM limits for distinct ECMP groups as more spines and prefixes are added. What IP fabric scaling constraint should the team treat as first-class in the design?
Select an answer to reveal the explanation.
Short Explanation
ECMP groups are like reserved parking lanes in silicon—once the garage’s painted spots (TCAM/FIB) are full, you cannot keep inventing new multipath sets. Hardware scale limits are a real Clos design constraint, not something keepalive timers or DNS will magic away.
Full Explanation
Municipal pods can approach hardware limits on distinct ECMP groups and FIB entries as spines and unique multipath sets multiply. Those ASIC constraints are first-class IP fabric scaling limits: BGP may still converge while the data plane can no longer program every desired multipath group. Designers must size pods, prefix uniqueness, and ECMP entropy with FIB/ECMP-group capacity in mind—not assume software session success equals unlimited hardware multipath.
DNS caching on the OOB management network does not determine how many ECMP groups the data plane can install. Increasing BGP keepalive timers does not expand TCAM or erase ECMP group limits. Only the number of VLANs on access ports does not constrain ECMP group scale in an IP fabric; access VLAN count is a different resource dimension.
Exam caveat: expect questions that separate control-plane liveness from hardware FIB/ECMP-group exhaustion; the correct theme is silicon scale, not timers or DNS.
Operational check: inventory unique ECMP groups and FIB utilization on representative leaves as spines are added; if approaching platform limits, reduce unique multipath sets via design (summaries, peer topology) before production host growth.