0

We have a pair of Cisco Nexus 3548 switches setup with HSRP acting as the network gateway for each of our network segments in a datacenter/VMware environment.

We wish to replace the Cisco Nexus switches with a pair of Juniper QFX switches. My understanding is that we can't run HRSP on the Junipers as that's a Cisco proprietary protocol so we'll need to replace that with VRRP (unless someone can suggest a better option).

My question is how can we (With the least amount of downtime) transition from the Cisco's to the Junipers. My initial thoughts would be to:

  1. Setup the Junipers with VRRP but with different IP addresses, test the config
  2. On deployment day disconnect the Junipers
  3. Change the VRRP IPs via the console to contain the IPs of the Ciscos
  4. Shutdown all of our VMs
  5. Shutdown the Cisco switches
  6. Connect the Junipers
  7. Power everything back up

Can anyone suggest a more elegant/less disruptive way of doing this?

Thanks!

Improve this question
  • 1
    Why would you shut down all VMs? – Teun Vink♦ Aug 24 '20 at 13:14
  • 1
    That step may be unnecessary. I am concerned what may break when we take away the default gateway temporarily. – Brad Aug 24 '20 at 13:37
  • 1
    Depending on the configuration, it may be necessary to shut them down (or bounce the interface) to flush the old gateway MAC address – Ron Trunk Aug 24 '20 at 13:53
  • You might want to add some detail about the L2/Switching environment between the HSRP speaking Cisco NX and the hypervisors with their VMs. Are the hypervisors directly attached to the Cisco NX? With (M)LAG, aka VPC using LACP? Are there Nexus 2000 Series Fabric Extenders in the mix? Looking at just the HSRP/VRRP part might make the problem appear too simple. – Marc 'netztier' Luethi Aug 25 '20 at 17:08
1

I think you should simply do the following:

  1. confirm reachability of downstream VMs prior to activity
  2. remove HSRP configuration from Cisco devices
  3. commit VRRP configuration to Juniper devices
  4. wait 60 seconds for most modern hosts' ARP caches to update
  5. re-confirm reachability of downstream VMs following activity

Adding steps such as shutting down your VMs will probably lengthen your outage duration, not decrease it. Modern ARP (and IPv6 ND) time-outs are shorter than you might guess; the defaults on Windows and Linux are a random value between 15 seconds and 45 seconds.

Further, if you wanted zero downtime, you could almost certainly achieve that. The easiest way would be to reverse the order of steps 2 and 3, above, and allow there to be a temporary IP conflict between the Juniper VRRP routers and the Cisco HSRP routers.

I'd personally go an extra step and remove one Cisco from HSRP (whichever is standby) and then remove its other layer-3 address (assuming it'll be needed for a new Juniper) then configure a one-host Juniper VRRP group, then remove the second Cisco, then add the second Juniper. That is a more complex operation but, in concert with routing protocols directing ingress traffic to the subnet, it is likely to offer a zero-downtime approach to this migration.

Improve this answer
  • While there is a conflict and arp caches are clearing won't their be a disruption to service? – Brad Aug 29 '20 at 13:06
  • The Ciscos will continue forwarding traffic for the hosts as long as they have at least one layer-3 address on the VLAN. If you just remove the HSRP config, but leave the primary IP address configured on whichever Cisco was the HSRP active group-member until after traffic transitions to the Junipers, there will be no traffic loss. – Jeff Wheeler Aug 30 '20 at 14:50
2

As per my understanding , you have a pair of Cisco NX Switches acting as HSRP gateway. You want to replace them with Juniper QFX switches which will be running VRRP as it is the IEFT standard protocol. The objective is to minimize the downtime.

Lets call your 2 x NX-OS switches , NX-OS-1 and NX-OS-2. Lets assume that NX-OS-1 is primary HSRP. Lets also call Juniper QFX switches , QFX-1 and QFX-2

You may proceed like this :-

  1. In the current scenario , replace HSRP with VRRP on NX-OS switches by doing configuration change. There will be glitch from services perspective. Verify that NX-OS-1 is VRRP master and NX-OS-2 is VRRP backup.

  2. Now shut down the NX-OS-2 (acting as VRRP backup). Before shutdown confirm that NX-OS-1 is VRRP master for all VRRP groups (or VLANs). Power on the Juniper QFX-1 and replace all the interfaces / cabling of NX-OS-2 with Juniper QFX-1.Perform VRRP configuration on QFX-1 and configure its priority low to make it backup VRRP.

  3. With NX-OS-2 being powered off , VRRP handshake takes place between Cisco NX-OS-1 and Juniper QFX-1. NX-OS-1 is the VRRP master while Juniper QFX-1 is the VRRP backup.

  4. Perform VRRP switchover from Cisco NX-OS-1 to Juniper QFX-1. This can be done by increasing the VRRP priority on Juniper QFX-1. Since VRRP master and backup share the same VIP (Virtual IP) and VMAC (Virtual MAC) , there should be no service disruptions (or outage) during switchover.

  5. Before proceeding forward , check that Juniper QFX-1 is master for all VRRP groups and that services are running fine.

  6. Since NX-OS-1 is now acting as VRRP backup , there should not be any traffic transiting through it (Check via MTRG graphs). We can safely power off the NX-OS-1.

  7. Power on the Juniper QFX-2 and replace all the interfaces / cabling of NX-OS-1 with Juniper QFX-2. Configure VRRP on QFX-2 and verify it is the backup of all VRRP groups.

Before conclusion , confirm again services are running fine.

Improve this answer
  • Thanks for the answer - this seems like a good approach although I suspect Jeffs answer below might be an even better approach. – Brad Aug 29 '20 at 13:05
  • @Brad. Actually from operations perspective, network migrations from X to Y vendor is always a slow and step by step approach. Making all changes in one night to shift the services from one vendor to another would generally creare chaos and also prolonge outage. It is recommended to proceed step by step as it helps to verify configuration changes repeatedly and fix issues quickly they arises. – NABEEL NASIR Aug 31 '20 at 16:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.