Forum Discussion

Ottimo_Massimo1's avatar
Ottimo_Massimo1
Icon for Nimbostratus rankNimbostratus
Jan 29, 2013

Migrating VIPs from one LTM pair to a new LTM pair

 

Hi,

 

I am planning on migrating several publicly IPed VIPs along with their associated SNATs, pools, irules, nodes, etc. from one LTM pair to another. I would have thought this was a relatively straightforward process, but i ran into some issues with my first attempt. so, I was wondering if anybody on this forum could provide some pointers or steer me in the direction of some decent documentation on the subject.

 

Would anybody be able to confirm if VIPs remain pingable even after they have been disabled? I noticed this behaviour during the previous migration window and had to back out of the migration. is it best practice to simply delete the VIPs before migrating them to another device?

 

 

Thanks!

 

 

8 Replies

  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    They sure do remain pingable (And thus responding to ARP requests)... I'm not sure I've ever found a good way to stop the device from responding to ARP requests... I've even tried disabling the virtual address. (That's in 10.2.4, I haven't verified v11, because I was doing the same as you. Upgrading :)

     

     

    H
  • Thanks Hamish. So, I guess the only way to ensure that the VIPs are not reachable via the old LTMs is to delete their configuration, wait for arp timeout and then enable them on the new LTMs.

     

  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Are you moving them one at a time? Or all at once? There's several choices to follow.

     

     

    If you're moving everything, you could force the unit to standby. A VLAN failsafe on a known down network is always good for that.

     

     

    If you're migrating one at a time (And don't want to migrate by changing the IP in DNS), you could also change the IP of the old VS to a VLAN that doesn't exist outside the LTM. That way you still have the old config around (I like this method myself where you can't reliable alter the IP address of the service. I configure the NEW VS with a new IP for testing. Then when people are happy, swap the IP's between the old & new VS).

     

     

    My favourite of course (IMO :) is just changing the IP. That way everything is all setup and tested as working ahead of time. The go-live is a simple DNS update. Failback is another DNS update. You set the DNS TTL way down to the minimum before the cutover so the DNS propagation is quick. If it's NATéd you can achieve the equivalent by just changing the firewall NAT rules. (I hate NAT BTW, so never recommend this one).

     

     

    H
  • Hi Hamish,

     

     

    Unfortunately I need to migrate all the VIPs in one go. You're idea of retaining the VIP configuration on the old LTMs with non-production IPs is a good one, or I could have the configuration ready to copy and paste if everything goes south.

     

     

    Thanks again for confirming that disabling the IPs does not mean that they become unreachable. This is exactly the behaviour I observed when I disabled the VIPs on my production LTMs.

     

  • I do believe you can disable ARP for a VS by doing so via the Virtual Address configuration rather than via the Virtual Server configuration. Of course, this is only useful if you only use one IP per VS, or at least not too many.
  • Thanks. I think the nuclear option of removing the IPs from the old LTMs might work best given the time frames for any migration work.
  • Just to confirm, WLB's suggestion also works. Disabling ARP responses from the VIPs as outlined here http://support.f5.com/kb/en-us/solutions/public/5000/700/sol5773.html?sr=27232089 has worked in my lab!