Ops proposes naively stretching the same IP fabric underlay ASN across two city data centers over the WAN. What boundary concern should be raised?
Select an answer to reveal the explanation.
Short Explanation
Gluing two city fabrics into one underlay ASN "just because" is like knocking down the firewall between two buildings and hoping for the best. Interconnect separate fabrics on purpose; do not accidentally build one giant underlay.
Full Explanation
Naively stretching the same IP fabric underlay ASN across two city data centers over the WAN risks merging failure domains, complicating routing policy, and turning a WAN event into a fabric-wide underlay event. Geographic DCs usually remain separate fabrics that are interconnected on purpose; stretching one underlay without deliberate design is risky. A single underlay ASN across cities is not mandatory for EVPN Type-5 exchange. Underlay ASN scope does matter for DCI even if VXLAN UDP is open. Stretching the underlay ASN does not automatically provide encrypted Internet DCI. Exam caveat: some carefully engineered multi-pod fabrics span campuses with one ASN—but that is intentional fabric design, not a shortcut for metro WAN DCI between independent halls. Operational check: keep separate underlay ASNs/fabrics per municipal DC unless a formal multi-pod design exists; interconnect with DCI borders; exchange overlay Type-5 or L2 EVPN as required; simulate WAN loss and confirm each fabric's underlay remains stable. Default to separate underlay fabrics per DC with deliberate DCI borders unless a formal multi-pod ASN design is approved. Default to separate underlay fabrics per DC with deliberate DCI borders unless a formal multi-pod ASN design is approved.