The network you support currently has a mixture of MC-LAG and Virtual Chassis being used...

In an EVPN-VXLAN environment using ESI-LAG (Ethernet Segment Identifier Link Aggregation) , the Core Isolation feature is a safety mechanism designed to prevent traffic blackholing. When a leaf switch (acting as a VTEP) loses its BGP peering or its link to the IP fabric core, it assumes it is " isolated " from the rest of the network. To protect the network, the switch automatically shuts down its local member links of any multi-homed ESI-LAG to force traffic to the peer switch that still has core connectivity.

However, during a migration or in specific transitional topologies where the core might be temporarily unreachable or not yet fully established, this feature can cause the leaf switches to shut down all downstream IDF (Intermediate Distribution Frame) connections, leading to a total loss of connectivity.

The Solution (Option C): By enabling the no-core-isolation statement under the [edit protocols evpn] hierarchy, you instruct the switch to disable this automatic shutdown behavior . This ensures that even if the BGP session or core links are not yet stable during the migration process, the ESI-LAG interfaces remain Up , allowing the IDFs to maintain connectivity to their local default gateways or other local resources.

Why others are incorrect: Enabling EVPN-VXLAN before migration (Option A) does not address the isolation logic. Removing MC-LAG/Virtual Chassis links prematurely (Option B) would cause an immediate outage. The network-isolation-profile (Option D) is typically used for different loop prevention scenarios and does not override the specific core-isolation check that affects multi-homed ESIs.