Data Center Challenges and Requirements

Lessons Discussion
1

This topic is to discuss the following lesson:

2

Rene,

Could you please share some ideas for migrating a data-center network from Arista to Juniper?— a step-by-step procedure (planning, inventory, config migration, testing, cutover, rollback) and call out common pitfalls?
Thanks,

Raju

3

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:

  1. 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.
  2. 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.
  3. 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

4

Hi Laz,

Thank you for taking the time to share your insights and high-level guidelines for the migration. I truly appreciate your input on defining the underlying architecture, selecting the right underlay/overlay technologies, and maintaining a clean L3 handoff during the transition from Arista to Juniper fabrics.

Your guidance gives me a clearer starting point for planning this project, and I value your expertise.

Best regards,
Raju

5

Hello Raju

Glad to hear it was helpful! I’d be interested to know how your migration is getting along as you prepare for and implement it.

Laz