Forum Discussion

Danny_Arroyo's avatar
Jun 07, 2018

Migrating from BigIP 2000 series to BigIP 2600 series

We currently have a BigIP 2000 LTM HA pair running v12.1.3.3 (we will be upgrading to 13.x soon). We purchased a comparable BigIP 2600 LTM HA pair. We are planning a migration to the 2600.

 

We have the luxury of being able to keep both F5 HA pairs in production for about a year which will allow us to migrate our VS' over slowly. The plan is to use different vlans for our dmz/public network (where our VS' live) on the 2600 series. The private vlans (where our nodes live) will not change when we migrate our nodes to the 2600 series.

 

My question is can I just import the complete backup of my 2000 series into the new 2600 series LTM (They will both be runing the same version 13.x)? Being that the VS's vlans are different, the VS's ips wont be able to ARP out (and the 2000 series will still be running the show). At this point, to enable the VS's on the 2600 series, I can change the VS's ip address to match the new vlans. Simultaneously, I can change the corresponding VS' ip address on the 2000 series to disable it. The Pools, Profiles, Certificates, Nodes, irules should all remain the same. Would that work? Am I missing something? What is the best way to do this?

 

My question is how can I import stuff like the nodes, Profiles, Certificates, pools, etc that are not going to change? Our VIP ip address' are the only things that will change

 

17 Replies

  • Hi Danny,

     

    If you wish to migrate to a device but change some of the configuration I would probably not use an archive of SCF to restore the new device.

     

    I would build the new device pair in isolation, configure your VLANS, trunks, self IPs, gateways, configure HA etc Then take a copy of the bigip.conf file from your existing device. Take this file offline to edit the IPs and VLANs and anything else that may change when deployed on the new kit.

     

    Copy the edited file to one of your new devices and run a merge verify command to see if there are any errors.

     

    tmsh load sys config file /var/tmp/edited-bigip.conf merge verify

     

    Work through any errors if there are any, if all is good - run the same command without the verify and sync to the peer.

     

    When you're ready, you can enable the VLANS on the F5 or local switch to cut over when you migrate.

     

    Lee

     

  • I Alredy do this stuff for on customer. I propose the following procedure:

    • don't connect the new device
    • Import the ucs (from old device) to new device:

    tmsh load sys ucs platform-migrate no-license: https://support.f5.com/csp/article/K82540512

    • Keep the same vlan for internal and external vlan just change selfIP and floating to avoid conflit IP (for both vlan). and change management IP also.

    At this momement you retrieve configuration in the new device and all your IP are in the same vlan but with different IP (mgmt, int and ext).

    retrieve all your VS IP in order to disable ARP using tmsh like this:

    • modify ltm virtual-address 10.1.2.123 arp disabled
    • modify ltm virtual-address 10.1.2.119 arp disabled
    • modify ltm virtual-address 10.1.2.118 arp disabled
    • modify ltm virtual-address 10.1.2.110 arp disabled
    • modify ltm virtual-address 10.1.2.109 arp disabled
    • ...

    And don't forget to save (save sys config), after what you can validate that all your arp in your new device are disabled using GUI (Local Traffic ›› Virtual Servers : Virtual Address List) or CLI, search "arp enabled" in /config/bigip.conf file.

    • So now you can connect it to the network.
    • connect the other one (2600) set network part with new IP and sync configuration.

    At this momement you have your 2 F5 archi (old and new) in your network.

    as soon as you want to migrate an application you have just to:

    Disable ARP (F5 2000)
    modify ltm virtual-address 10.1.2.123 arp disabled
    save sys config
    
    Enable ARP (F5 2600)
    modify ltm virtual-address 10.1.2.123 arp enabled
    save sys config
    

    It's easy to migrate your service and you can go back easly...

  • Hi Danny,

     

    There's one VERY important question that I don't think has been addressed: what modules are you running on the 2000s? In my experience, the modules may dictate the migration path. UCS, SCF or bigip.conf are your basic options. This is the way I've approached similar migrations in the past:

     

    LTM: export SSL certificates and SCF file. Edit SCF file keeping LTM objects

     

    LTM and GTM/DNS: export SSL certificates and SCF file. Edit SCF file keeping GTM and LTM objects

     

    APM: export UCS file. Verify your interfaces are offline on new environment. Import UCS file using "no-platform-check no-license " options

     

    ASM: export ASM profiles. Load ASM profiles to new environment then load LTM objects (see LTM procedure above)

     

    • Danny_Arroyo's avatar
      Danny_Arroyo
      Icon for Cirrus rankCirrus

      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?

       

    • AceDawg1's avatar
      AceDawg1
      Icon for Nimbostratus rankNimbostratus

      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.).

    • Danny_Arroyo's avatar
      Danny_Arroyo
      Icon for Cirrus rankCirrus

      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,

     

    There's one VERY important question that I don't think has been addressed: what modules are you running on the 2000s? In my experience, the modules may dictate the migration path. UCS, SCF or bigip.conf are your basic options. This is the way I've approached similar migrations in the past:

     

    LTM: export SSL certificates and SCF file. Edit SCF file keeping LTM objects

     

    LTM and GTM/DNS: export SSL certificates and SCF file. Edit SCF file keeping GTM and LTM objects

     

    APM: export UCS file. Verify your interfaces are offline on new environment. Import UCS file using "no-platform-check no-license " options

     

    ASM: export ASM profiles. Load ASM profiles to new environment then load LTM objects (see LTM procedure above)

     

    • Danny_Arroyo's avatar
      Danny_Arroyo
      Icon for Cirrus rankCirrus

      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?

       

    • AceDawg_204810's avatar
      AceDawg_204810
      Icon for Cirrus rankCirrus

      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.).

    • Danny_Arroyo's avatar
      Danny_Arroyo
      Icon for Cirrus rankCirrus

      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?

       

  • Thank you all for your help. Given all the responses, I believe I have enough information to get this done efficiently and with minimal issues.