Migrating from BigIP 2000 series to BigIP 2600 series

Hi AceDawg1,

Good point. We ony use LTM.

I've used the UCS and bigip.conf in the past but, I'm not familiar with the SCF file. Can you explain the SCF method?

Hi Danny,

If I am following you correctly, it sounds like you are changing some of the networking for this project (e.g. VIP addresses). Correct me if I am wrong but I assume you'll be changing DNS entries to point to the new VIPs. If my assumptions are correct, then this is the procedure I would use:

NOTE: I would download the trial version of BIGIP (https://devcentral.f5.com/articles/getting-started-with-big-ip-ve-trial-22469) and test in a VMWare environment before going to prod

STRONG NOTE: Be sure to verify that the backend servers/nodes are NOT using the F5 as their default gateway. If they are, then it will change the way you approach the networking portion of your migration. You may have to involve the server team in the event this is the case (we can discuss further). Look for FTP and SMTP virtual servers in your F5 environment. While not an exclusive list, typically, these are the devices that fall under this category.

1. UI (2000): System->File Management->SSL Certificate List->Select pertinent certificates->[Archive]
2. UI (LAB or 2600): System->File Management->SSL Certificate List->[Import]->Import Type: Archive

3. TMSH (2000): tmsh save sys config file devicename_datestamp.scf no-passphrase:

   tmsh save sys config file danny2000_20180607.scf no-passphrase

4. Download scf file (e.g. danny2000_20180607.scf) to your local workstation

5. Using notepad++, hand edit the danny2000_20180607.scf file removing all stanzas EXCEPT for those beginning with ltm. In other words, you would only keep the ltm objects (see below):

   ltm default-node-monitor {
       rule /Common/icmp
   }
   ltm node /Common/10.33.13.232 {
       address 10.33.13.232
   }
   ltm pool /Common/SOMEPOOL_HTTP {
       description SOMEPOOL_HTTP
       members {
           /Common/10.33.13.232:80 {
               address 10.33.13.232
           }
       }
       monitor /Common/SOMEMONITOR_HTTP
   }
   ltm monitor http /Common/SOMEMONITOR_HTTP {
       adaptive disabled
       defaults-from /Common/http
       description SOMEMONITOR_HTTP
       destination *.*
       interval 5
       ip-dscp 0
       recv none
       recv-disable none
       send "GET /\r\n"
       time-until-up 0
       timeout 16
   }
   ltm rule /Common/MOBILECARE-TEST-X-FORWARDED {
       when HTTP_REQUEST {
   
        if {[HTTP::header exists X-Forwarded-For]}{
             HTTP::header replace X-Forwarded-For [IP::client_addr]
   
        } else {
             HTTP::header insert X-Forwarded-For [IP::client_addr]
        }
   }
   }
   ltm virtual /Common/SOMEVIRTUAL_HTTP {
       description SOMEVIRTUAL_HTTP
       destination /Common/10.0.0.10:80
       ip-protocol tcp
       mask 255.255.255.255
       pool /Common/SOMEPOOL_HTTP
       profiles {
           /Common/tcp { }
       }
       source 0.0.0.0/0
       source-address-translation {
           type automap
       }
       translate-address enabled
       translate-port enabled
   }
   

6. Using notepad++, change the VIP addresses on the ltm virtual server objects

7. TMSH (LAB or 2600): Perform test import of the modified danny2000_20180607.scf file and address issues:

   tmsh load sys config file danny2000_20180607.scf merge verify

8. TMSH (LAB or 2600): Perform import of the modified danny2000_20180607.scf file:

   tmsh load sys config file danny2000_20180607.scf merge

9. TMSH (LAB or 2600): Configure networking (VLANS, self-ip addresses, default router, etc.)
10. Create local host entry on workstation to test functionality
11. If all works out, modify DNS to point to new VIP

Admittedly, this is a more iterative approach than the others presented. Since this is a year long "rolling" migration as opposed to a cut migration, it gives you ample opportunity to address issues, test and truly dig into environment. Also gives you an opportunity to address oddities that inevitably leak into most F5 setups (e.g. naming conventions, profiles, etc.).

Hi AceDawg1,

Your assumptions are correct. Our F5 is not the default gateway for any of our devices, but good point. I like your approach, but just so I understand correctly, your approach will start after I run the initial config of the 2600's, correct?

From what you are describing, the SCF file is very similar to the bigip.conf file. Why choose the SCF file and not the bigip.conf file to make the changes?

When merging the SCF file, I would rather not change the VS ips because I don't want them to atart ARPing (on the new F5s) and causing havoc. I would like to change the IPs of our VS one by one until we are done with them all. Would that work?

Hi Danny,

To your questions:

1. Not sure what you mean by "run the initial config". Can you explain further?
2. Feel free to use the scf file or bigip.conf -- both should get you where you need to go.3. Understood. But if the VIP addresses are changing from the 2000 to the 2600, what is the issue with the new VIP addresses ARP'ing? The addresses are different between the 2000 and 2600 so no traffic "should" get to the new VIPs unless something explicitly points to them.

If ARP'ing is an issue for the environment for reasons of operational control, security, etc., then I would do the following:

1. Import LTM objects
2. Disable ARP as Youssef explained:

   modify ltm virtual-address 10.1.2.123 arp disabled

3. Provision the VLAN the VIPs reside on
4. Enable ARP:

   modify ltm virtual-address 10.1.2.123 arp enabled

Hi AceDawg1,

1. by "run the initial config" I mean the first step in configuring the F5 after giving it an ip address. Basically the Setup config. Hope that makes sense
2. Thanks for your explanation of the ARPing concern I have. You are right. It seems I had a mental block in my thinking. I was thinking that I wanted to keep the VS' ip address' the same on the old and new unit, but disable ARPing so that there are no conflicts. Then change the address on the new unit and enable ARPing when ready. By changing the ips (like you said) ARPing will not be a concern. I will change the ip address' when modifying the SCF file as you suggested.

Thanks again.

Yes. The procedure I laid out would be done after the "initial config"/setup.