A single municipal border leaf terminates every DCI stitch for three sites and now shows high control-plane and forwarding load. What design lesson should the fabric team apply?
Select an answer to reveal the explanation.
Short Explanation
One border doing every stitch is like one bridge carrying every city bus route—it works until rush hour. Stitch gateways need horsepower and backup paths, not a lone hero leaf. Scale and redundancy belong in the DCI placement plan from day one.
Full Explanation
When one municipal border leaf terminates every DCI stitch for three sites and saturates control-plane and forwarding resources, the design lesson is to plan stitch-gateway capacity and redundancy so stitch points are not single scaling hotspots. Stitch PEs carry EVPN route scale, encapsulation, and often BUM or mobility churn for multiple civic tenants; concentrating all of that on one leaf creates an operational bottleneck and a single failure domain for the city’s interconnect. Moving all stitch work onto the WAN provider CPE so leaf CPU is “never a fabric concern” outsources a fabric-owned overlay control plane without solving capacity planning and may remove visibility the municipal NOC needs. Disabling EVPN on the border and relying on flood-and-learn across the interconnect for scale reverts to legacy unknown flooding, increases WAN BUM, and contradicts EVPN-VXLAN DCI blueprints. Collapsing every tenant into one VNI so the border stitches a single overlay forever destroys isolation between departments and trades a CPU problem for a security and blast-radius crisis. Exam caveat: stitch gateways are capacity objects—design redundancy and headroom, do not invent a single mega-VNI to hide load. Operational check: measure EVPN route counts, VXLAN encapsulation PPS, and RE/CPU on each stitch gateway under peak civic mobility; add or load-share dual stitch borders, confirm failover, and document per-site stitch capacity in the municipal fabric capacity plan.