County elections planners want a fabric-capable underlay so a future SD-Access overlay is not stranded for bandwidth or leaf capacity. Which high-level design consideration should they prioritize first?
Select an answer to reveal the explanation.
Short Explanation
Fabric overlays ride on the underlay like buses on city streets—if the streets are too narrow, fancy buses still stall. Size the underlay leaf-spine paths and scale first so later SD-Access overlays have room to breathe.
Full Explanation
County elections planners preparing a fabric-capable underlay must prioritize leaf-spine (or equivalent underlay) bandwidth, oversubscription ratios, and scale limits so a future SD-Access overlay is not stranded for capacity. Overlays encapsulate and steer traffic, but they still consume underlay forwarding, buffering, and leaf port scale. Sizing those resources first creates headroom for election-day peaks, voting kiosk bursts, and later fabric services without redesigning the physical underlay mid-cycle.
Disabling Spanning Tree everywhere so fabric edges can flood freely during peaks attacks Layer 2 loop protection and does not substitute for underlay capacity planning. Replacing every access switch with wireless controllers before underlay sizing confuses WLAN architecture with fabric underlay engineering. Publishing only public DNS for voting kiosks is an application naming choice that does nothing to ensure leaf-spine bandwidth or fabric scale.
Exam caveat: ENCOR fabric questions often test that overlays ride an IP underlay; capacity and scale of that underlay are first-order design inputs. Do not confuse control-plane fabric features with an excuse to ignore oversubscription.
Operational check: model concurrent election sites and kiosk traffic, measure current leaf-spine utilization, document oversubscription targets, and confirm leaf port and ECMP scale leave headroom for overlay encapsulation overhead before committing to SD-Access timelines for the county.