Security asks that DCI EVPN signaling for the municipal interconnect run in a dedicated routing instance rather than sharing the production tenant instance casually. What design hygiene does that request reflect?
Select an answer to reveal the explanation.
Short Explanation
Giving DCI its own routing instance is like putting the interconnect radio room on a separate floor—cleaner blast radius and clearer policy. Separation keeps signaling and import/export hygiene intentional. It does not delete the need for RTs or VTEPs; it organizes them.
Full Explanation
When security asks that DCI EVPN signaling for the municipal interconnect run in a dedicated routing instance rather than casually sharing a production tenant instance, that request reflects isolating DCI signaling and related policies in appropriate routing instances as control-plane separation. Separating interconnect BGP EVPN peering, policies, and sometimes loopback/VTEP context reduces blast radius if a tenant VRF is misconfigured and clarifies which instance owns multi-site signaling. It is false that all EVPN must share one global routing instance or multi-site DCI cannot function; Junos routing instances are commonly used to separate tenants and services. Security or interconnect instances are not limited to firewall filters and unable to carry BGP EVPN families—BGP EVPN can be configured in the appropriate instance design. Dedicated instances do not remove the need for route targets or VTEP addressing on borders; they organize where those controls live. Exam caveat: instance separation is hygiene for DCI control planes—it complements, not replaces, RT and VTEP design. Operational check: confirm municipal DCI EVPN neighbors and policies live in the intended routing instance, that tenant VRFs import only approved multi-site routes, and that a mispolicy in one tenant instance cannot advertise arbitrary routes into the interconnect signaling instance; document the instance map for auditors.