Hello Raju
I don’t have direct experience with a specific project such as this with the specific vendors you mention, however, I can give you some high-level guidelines for planning and implementing such a migration.
Initially, you should define the underlying architecture (i.e. EVPN-VXLAN). Choose your underlay and overlay technologies, and keep a clean L3 handoff between Arista and Juniper fabrics during migration.
Your inventory and discovery process should include:
- Physical - every spine/leaf ToR ports, uplinks, cable maps optics part numbers and power feeds
- Logical - VLAN/VNI mappings, VRFs/RTs/RDs, BGP neighbors, route policies QoS/ACLs, CoPP
- Endpoints - servers, LAGs, hypervisors, storage appliances etc
- Dependencies: DHCP relays, DNS, monitoring and telemetry
The above is just an indicative list of things to record. In any case, you should create a document like a spreadsheet to map the Arista entities to Juniper entities. This will become the blueprint for your translation/migration. Use this blueprint to begin the configuration translation process.
Next, this should be used to build a lab/staging environment. This can be virtual or it can be a scaled down physical topology, depending on what equipment you have access to. Here you can test thing like addressing and RT/RD patterns. You can test BGP EVPN peerings and validate operations. Here you can prove your config migration implementation.
Then you must choose a migration plan. Typical migration plans follow one of these three:
- Rack-by-rack (L2 move + L3 steady): Extend VLANs/VNIs from Arista to Juniper temporarily, move server LAGs to new Juniper leaves, keep north-south L3 at old fabric until rack drained.
- VRF-by-VRF (L3 first): Stand up VRF on Juniper, move L3 default gateway and advertise routes. L2 may remain local per rack, then move access.
- Side-by-side new fabric: New Juniper fabric peers at L3 to old (EVPN or plain IP). Migrate services in chunks; decommission old later.
Typically, 1 or 3 is chosen because it isolates the impact range of failures, and and avoids cross vendor multi homing.
Once all of that is done, you get to the pre-cutover checklist, the cutover procedure, and then the post-cutover validation. These should be based on the above work that you have done.
Finally you should have a rollback procedure in place with specific checkpoints as you go along.
Some pitfalls that you should be aware of:
- Optics used by one vendor may not be compatible with those of the other. These should be pre-validated
- MTU should be set throughout on all equipment
- Cross-vendor multi-homing should be avoided
- RD/RT mismatches are easy to create, and difficult to discover and troubleshoot
- Some default values such as those for QoS or CoPP or route policies may be different on vendors, and should be explicitly configured
- Licensing and features must be prevalidated to ensure that they are operational when migrating to new equipment
This is by no means exhaustive, however, it may be a useful starting point for your project.
I hope this has been helpful!
Laz