A small township wants its first EVPN-VXLAN fabric with fewer devices holding complex tenant routing features. Why might CRB be chosen operationally?
Select an answer to reveal the explanation.
Short Explanation
For a first small-town fabric, CRB is like putting the fancy routers only at city hall and keeping leaf switches simpler. You still run EVPN — you just concentrate routing state centrally. It is a tradeoff, not a free latency win or a no-BGP shortcut.
Full Explanation
CRB can be chosen operationally for a small township's first EVPN-VXLAN fabric because routing features, IRB state, and some troubleshooting concentrate on fewer spine or border devices, letting first-build leaves remain simpler L2 VTEPs. That operational simplification is the rationale—not a claim that CRB removes BGP EVPN from the fabric. CRB does not eliminate the EVPN control plane. CRB does not always provide lower latency than ERB for every east-west flow; hairpinning often adds a hop. CRB does not require every leaf to run full anycast IRB on day one—that requirement is ERB-like. Exam caveat: simpler leaves can become scarcer central TCAM as MAC/host scale grows—plan the exit ramp toward ERB if the municipal fabric expands. Operational check: deploy a pilot tenant with IRBs only on spines, measure leaf config size versus spine IRB scale, document east-west path length, and record when central state approaches platform limits. Schedule a CRB-to-ERB review when spine host scale or TCAM alarms approach thresholds defined in the township capacity plan. Schedule a CRB-to-ERB review when spine host scale or TCAM alarms approach thresholds defined in the township capacity plan. Schedule a CRB-to-ERB review when spine host scale or TCAM alarms approach thresholds defined in the township capacity plan.