Applies To:

Show Versions Show Versions

Manual Chapter: Migrating Configurations Using the OTCU
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

After you install the Local Traffic ManagerTM software, you may choose to rebuild your configuration settings manually, which is ideal for systems with minimal configuration, and an opportunity to see the differences in the features you use. Alternatively, you can hire a consultant from F5 Networks to perform the migration for you.
A third option is to migrate your previous configuration settings to Local Traffic Manager using the one-time conversion utility (OTCU). The OTCU converts the BIG-IP version 4.x configuration files, bigip_base.conf and bigip.conf, into a format that Local Traffic Manager can support.
Important: The OTCU was developed specifically for BIG-IP versions 4.2 to 4.5.12. If you are running BIG-IP version 4.5.13 or later, be aware that the OTCU may fail, or might not fully migrate all of the settings in the UCS archive to Local Traffic Manager. If you successfully migrate the settings for BIG-IP version 4.5.13 or later, you must re-create any configuration settings for features introduced after version 4.5.12.
3.
At the prompt, type y to run the OTCU.
The OTCU displays a warning message that it may be unable to convert all objects to Local Traffic Manager.
4.
Review the message, and type y to proceed.
The OTCU prompts you to configure the management port.
5.
If you have already configured the management port, press c to keep the current settings; otherwise, press n to configure new network settings.
When prompted, consolidate profiles and do not rename configuration objects; however, before consolidating the profiles, carefully review the settings to ensure you select the proper profiles.
When prompted to configure the time zone, you configure two settings: the first to specify the appropriate country or region, the second to specify the time zone within that region.
After you provide the required information, the OTCU attempts to load the bigip.conf and bigip_base.conf files. If these files fail to load, the system stops the process and renames the files bigip.conf.otcu and bigip_base.conf.otcu, respectively. You can run the b load command to view information to identify the configuration problem. Once you identify the issues, fix them in the configuration files using a standard text editor, and then run the b load command until the files load successfully.
7.
Once the bigip.conf and bigip_base.conf files have successfully loaded, reboot the system.
The system initializes as Local Traffic Manager.
Because the Local Traffic Manager has specific platform requirements (as outlined in the Local Traffic Manager release notes), you may be upgrading your hardware along with your software. The OTCU is designed to allow you to take a UCS file from a BIG-IP version 4.x system, and use that file to run the OTCU on another platform, such as a 1500, that is licensed to run Local Traffic Manager version 9.x.
Important: The OTCU was developed specifically for BIG-IP versions 4.2 to 4.5.12. If you are running BIG-IP version 4.5.13 or later, be aware that the OTCU may fail, or might not fully migrate all of the settings in the UCS archive to Local Traffic Manager. If you successfully migrate the settings for BIG-IP version 4.5.13 or later, you must re-create any configuration settings for features introduced after version 4.5.12.
When performing the following steps, keep in mind that the bigip_base.conf file may not load properly if the interface and VLAN configuration is not the same on both platforms (that is, the platform on which you created the UCS and the platform on which you run the OTCU). To minimize potential issues, first configure the basic network components (VLANS, self IP addresses, management port, and so forth) on the Local Traffic Manager version 9.x platform, before you use this procedure to run the OTCU.
1.
On a licensed Local Traffic Manager version 9.x system (for which you have configured the basic network components and verified network connectivity), back up the bigip.conf and bigip_base.conf files using the following commands:
2.
On the BIG-IP version 4.x system, save a backup of the UCS file by typing the following command:
3.
Copy the otcu.ucs file to the Local Traffic Manager system by typing the following command:
4.
Start the OTCU by typing the following command:
5.
At the prompt, type y to run the OTCU.
The OTCU displays a warning message that it may be unable to convert all objects to Local Traffic Manager.
When prompted, consolidate profiles and do not rename configuration objects; however, before consolidating the profiles, carefully review the settings to ensure you select the proper profiles.
When prompted to configure the time zone, you configure two settings: the first to specify the appropriate country or region, the second to specify the time zone within that region.
After you provide the required information, the OTCU attempts to load the bigip.conf and bigip_base.conf files. If these files fail to load, the system stops the process and renames the files bigip.conf.otcu and bigip_base.conf.otcu, respectively. You can run the b load command to view information to identify the configuration problem. Once you identify the issues, fix them in the configuration files using a standard text editor, and then run the b load command until the files load successfully.
7.
Once the bigip.conf and bigip_base.conf files have successfully loaded, copy the original configuration files back into place by typing the following commands:
8.
Reboot the system.
The system initializes as Local Traffic Manager.
bigip_base.conf
Contains the configured VLANs, self IP addresses, management interface, and so forth.
bigip.conf
Contains the specific settings for each of the virtual servers and pool members.
When you use the OTCU, it migrates your current BIG-IP version 4.x settings to Local Traffic Manager version 9.x. Given the wide variety of configurations for BIG-IP systems, it is not possible to anticipate every issue that may arise during this migration process; after you run the OTCU you must carefully review these files to ensure that the configuration converted correctly.
The sections that follow provide you with sample configuration files as they existed in BIG-IP version 4.x, and how the files appear after the settings are migrated to Local Traffic Manager version 9.x. These examples can help you to identify some of the potential issues and assist you in how to address them.
The bigip_base.conf file contains the basic configuration settings for your network such as the VLANs, self IP addresses, and the management interface. The following sections show a sample bigip_base.conf file, before and after running the OTCU.
This is a sample BIG-IP version 4.x bigip_base.conf file as it existed before the conversion.
Following is the bigip_base.conf file after the OTCU converts the settings to Local Traffic Manager version 9.x.
self allow { default tcp https tcp domain tcp snmp udp snmp tcp ssh tcp 4353 udp efs udp domain udp 4353 proto ospf }
The OTCU assigned the 1.1 interface as the management interface. This is important to note, because the 1.1 interface may have been used to load balance traffic prior to the upgrade.
The Local Traffic Manager routed remote authentication traffic through a Traffic Management Microkernel (TMM) switch interface (that is, an interface associated with a VLAN and a self IP address), rather than through the management interface. Therefore, if the TMM service stops for any reason, those interfaces are not available until the service is running again. In contrast, the management interface is available even if TMM is down, because it is hosted by Linux. Because of this change, you must provision for the management interface when migrating to Local Traffic Manager.
The OTCU modified the self allow statement to display the allowed default ports.
The Local Traffic Manager created a Spanning Tree Protocol (STP) instance, stp instance 0, even on non-switch platforms. If this line is removed, the Local Traffic Manager re-creates it the next time the system is booted or the bigip_base.conf file is loaded.
The bigip.conf file contains all of the settings for the virtual servers and pool members. There are several differences between the way BIG-IP version 4.x and Local Traffic Manager version 9.x operate. For example, in version 9.x persistence is a separate profile that you assign as an attribute to a virtual server, while in version 4.x, persistence is a function of a pool. When you review the converted bigip.conf file, you must look at the virtual server configuration as well as the pool(s) to ensure that all settings converted successfully.
Also keep in mind that some of the objects and functionality that exist in version 9.x do not directly match to objects and functionality that existed in version 4.x. Although the OTCU attempts to keep the original functionality intact, you may still need to modify some settings to ensure the most accurate conversion.
The following sections provides examples of the bigip.conf file before and after the conversion for these objects:
The following sample bigip.conf files are for an HTTP virtual server configuration, before and after running the OTCU.
This is a sample HTTP virtual server configuration as it existed in the BIG-IP version 4.x big.conf file, before the conversion.
virtual 172.24.55.135:http unit 1 {
use pool http_pool
svcdown_reset enable
Here is the big.conf file after the OTCU converted the settings to Local Traffic Manager version 9.x.
The OTCU dropped the reset on service down option from the virtual server, because in Local Traffic Manager version 9.x, the reset on service down option is a function of the pool. You can re-enable this option by modifying the advanced properties of the pool, http_pool.
The OTCU converted cookie persistence that existed on the BIG-IP version 4.x pool into a cookie persistence profile, cookie, and added it as an attribute to the virtual server.
The OTCU assigned the http_mon monitor as an attribute to the pool, http_pool, because in Local Traffic Manager version 9.x, you assign monitors to pools and/or pool members.
The OTCU assigned the TCP profile, tcp, as an attribute to the virtual server, notifying TMM that the transport protocol is TCP and directing TMM to service this virtual server in full proxy mode.
The OTCU assigned the HTTP profile, http, as an attribute to the virtual server, prompting TMM to use its full HTTP parsing logic when servicing this virtual sever.
Note: The OneConnectTM profile is a crucial web server optimization feature that reduces the TCP overhead of the load balanced pool members, and is a helpful addition to the virtual server. In Local Traffic Manager, OneConnect is a standalone profile that you must explicitly apply to the HTTP virtual server.
The following sample bigip.conf files are for an FTP virtual server configuration, before and after running the OTCU.
virtual 172.24.55.135:ftp unit 1 {
use pool ftp_pool
svcdown_reset enable
pool ftp_pool {
member 172.24.40.2:ftp ratio 5
member 172.24.40.5:ftp
Here is the big.conf file after the OTCU converted the settings to Local Traffic Manager version 9.x.
virtual vs_172_24_55_135_21 {
ip protocol tcp
pool ftp_pool
The OTCU dropped the reset on service down option from the virtual server, because in Local Traffic Manager version 9.x, the reset on service down option is a function of the pool. You can re-enable this option by modifying the advanced properties of the pool, ftp_pool.
The OTCU assigned the tcp monitor as an attribute to the converted pool, ftp_pool, because in Local Traffic Manager version 9.x, you assign monitors to pools and/or pool members.
The OTCU assigned the TCP profile, tcp, as an attribute to the virtual server, notifying TMM that the transport protocol is TCP and directing TMM to service this virtual server in full proxy mode.
The OTCU assigned the FTP profile, ftp, as an attribute to the virtual server, prompting TMM to listen for an associated FTP Data connection on port 20 for active FTP transfers.
The following sample bigip.conf files are for a DNS UDP virtual server configuration, before and after running the OTCU.
This is a sample DNS UDP virtual server configuration as it existed in the BIG-IP version 4.x big.conf file, before the conversion.
virtual 172.24.55.135:domain unit 1 {
use pool dns_pool
pool dns_pool {
member 192.168.11.1:domain
Here is the big.conf file after the OTCU converted the settings to Local Traffic Manager version 9.x.
virtual vs_172_24_55_135_53 {
The OTCU assigned the monitor, udp, as an attribute to the pool, dns_pool, because in Local Traffic Manager version 9.x, you assign monitors to pools and/or pool members.
The OTCU assigned the UDP profile, udp, as an attribute to the virtual server, prompting TMM to use UDP as the transport protocol when servicing this virtual sever. Because there is no DNS-specific profile in Local Traffic Manager version 9.x, the UDP profile is used to load balance DNS requests.
Note: Because DNS is a single packet transaction, you can configure the UDP profile, udp, to load-balance each packet individually. To do this, create a custom UDP profile with the Datagram LB option enabled, and then associate the profile with the DNS virtual server. For further details, see the Configuration Guide for BIG-IP® Local Traffic Management.
The following sample bigip.conf files are for an SSH TCP virtual server configuration, before and after running the OTCU.
This is a sample SSH TCP virtual server configuration as it existed in the BIG-IP version 4.x big.conf file, before the conversion.
virtual 172.24.55.135:ssh unit 1 {
use pool ssh_pool
conn rebind enable
member 172.24.40.2:ssh priority 2
Here is the big.conf file after the OTCU converted the settings to Local Traffic Manager version 9.x.
virtual vs_172_24_55_135_22 {
destination 172.24.55.135:ssh
ip protocol tcp
pool ssh_pool
The OTCU dropped the connection rebind option from the virtual server, because this function is deprecated in Local Traffic Manager version 9.x.
The OTCU assigned the TCP monitor, tcp, as an attribute to the converted pool, ssh_pool, because in Local Traffic Manager version 9.x, you assign monitors to pools and/or pool members.
The OTCU assigned the TCP profile, tcp, as an attribute to the virtual server, prompting TMM to use TCP as the transport protocol when servicing this virtual sever. Because there is no SSH-specific profile in Local Traffic Manager version 9.x, the TCP profile is used to load balances DNS requests.
The following sample bigip.conf files are for a wildcard any service virtual server with gateway pool configuration, before and after running the OTCU.
This is a sample wildcard virtual server configuration as it existed in the BIG-IP version 4.x big.conf file, before the conversion.
Here is the big.conf file after the OTCU converted the settings to Local Traffic Manager version 9.x.
virtual vs_0_0_0_0_any {
To resolve this issue, you can create a virtual server with IP address and port 0.0.0.0:21 and assign the default TCP and FTP profiles, and disable the Port Translation option. Then, configure that virtual servers default pool to be the same as the default gateway pool.
The OTCU assigned the FastL4 profile, fastL4, as an attribute to the virtual server. In Local Traffic Manager version 9.x, a wildcard virtual server can handle any service and transport protocol. The FastL4 profile is the default profile, because it processes TCP, UDP, and any other IP protocol.
The OTCU created a route statement for the default gateway in the bigip.conf file, because TMM has a separate routing table from that of Linux. You can view the routes for TMM using the b route list command.
The OTCU did not properly assign the monitor to the pool, gw_pool; as a result, the system is not currently monitoring that pool.
To resolve this issue, you can verify that the monitor converted successfully and then assign it to the pool, gw_pool.
The OTCU did not convert the IP Forwarding functionality, because Local Traffic Manager version 9.x is completely stateful; it has no equivalent to the IP Forwarding functionality that existed in BIG-IP version 4.x. To simulate IP forwarding behavior, you must create a custom FastL4 profile, enable both the Loose Initiation and Loose Close options, and then assign that profile to the virtual server.
The following sample bigip.conf files are for a network forwarding virtual server and forwarding pool configuration, before and after running the OTCU.
This is a sample forwarding virtual server and forwarding pool configuration as it existed in the BIG-IP version 4.x big.conf file, before the conversion.
Here is the big.conf file after the OTCU converted the settings to Local Traffic Manager version 9.x.
To correct this issue, you must remove the arp enable setting from the virtual server. If you do not remove this setting, the virtual server will respond to any ARP requests for any address in the 172.24.0.0/16 network range.
The OTCU incorrectly converted the virtual server so that it may be unable to properly handle active mode FTP transfers.
To resolve this issue, you can create a virtual server with IP address and port 0.0.0.0:21 and the default TCP and FTP profiles, and then disable the Port Translation option. Then, configure that virtual servers default pool to be the same as the default gateway pool.
The OTCU assigned the TMM default route for forwarding packets. For this sample configuration, no pool is required. You can change this option by specifying another route.
The following sample bigip.conf files are for an SSL terminating proxy configuration, before and after running the OTCU.
This is a sample SSL proxy, target virtual server and pool configuration as it existed in the BIG-IP version 4.x big.conf file, before the conversion.
redirects rewrite all
netmask 255.255.255.255
use pool http_pool
lb_method predictive_member
persist cookie
cookie_mode insert
member 172.24.40.5:http
member 172.24.40.2:http
Converted proxy, target virtual server, and pool
Here is the big.conf file after the OTCU converted the settings to Local Traffic Manager version 9.x.
The OTCU logged an entry that it skipped a virtual server. This OTCU log entry is of no concern, because Local Traffic Manager version 9.x does not require target virtual servers to perform SSL decryption or re-encryption, and the virtual server that was skipped was used only for the SSL proxy.
Note: In Local Traffic Manager version 9.x, you can no longer use 127.x.x.x addresses for virtual servers.
The OTCU placed the SSL settings (including the certificate and key files) in a ClientSSL profile and assigned that profile to a virtual server. You have the option to configure SSL re-encryption in a ServerSSL profile, and associate both ClientSSL and ServerSSL profiles to the same virtual server.
The OTCU associated the HTTP profile, http, to the virtual server, because redirect re-writes consist of re-writing HTTP headers, which is facilitation by the HTTP profile.
The OTCU converted any cookie persistence that existed in the BIG-IP version 4.x pool to a cookie persistence profile, persist, and added that profile as an attribute to the virtual server.
The OTCU assigned the monitor, http_mon, as an attribute to the converted pool, http_pool, because in Local Traffic Manager version 9.x, you assign monitors to pools and/or pool members.
Note: The OneConnectTM profile is a crucial web server optimization feature that reduces the TCP overhead of the load balanced pool members, and is a helpful addition to the virtual server. In Local Traffic Manager, OneConnect is a standalone profile that you must explicitly apply to the HTTP virtual server.
The following sample bigip.conf files are for an HTTP virtual server with cookie persistence, a pool selecting iRule, and pools configuration, before and after running the OTCU.
This is a sample HTTP virtual server configuration using iRules and pools as it existed in the BIG-IP version 4.x big.conf file, before the conversion.
use rule http_content
limit 1000
member 172.24.40.3:http
member 172.24.40.4:http
lb_method predictive_member
persist cookie
cookie_mode insert
member 172.24.40.5:http
member 172.24.40.2:http
Here is the big.conf file after the OTCU converted the settings to Local Traffic Manager version 9.x.
The OTCU applied the cookie insert persistence setting to the virtual server. This is because in Local Traffic Manager version 9.x, persistence is applied at the virtual server level, rather than the pool level.
Note: The OneConnectTM profile is a crucial web server optimization feature that reduces the TCP overhead of the load balanced pool members, and is a helpful addition to the virtual server. In Local Traffic Manager, OneConnect is a standalone profile that you must explicitly apply to the HTTP virtual server.
Converted the or statement in the iRule.
In Local Traffic Manager version 9.x, the syntax of the logical or statement requires the evaluated expression is explicitly restated.
To correct the iRule, use the [HTTP::uri] ends_with expression for each logical or statement.
Left persistence enabled on the pool, image_pool.
Because persistence is enabled at the virtual server level, it must be negated by the iRule when using the pool, image_pool.
To correct the iRule, remove the persist cookie insert statement.
Converted the else statement in the iRule; it contains the persist cookie insert statement, which is unnecessary because cookie persistence was applied to the virtual server.
To correct the iRule, you must remove the persist cookie insert statement and include the persist none command to prevent Local Traffic Manager from inserting a persistence cookie for this pool.
rule http_content_1 {
if { [HTTP::uri] ends_with ".jpg" or [HTTP::uri] ends_with ".gif" or [HTTP::uri] ends_with ".png"} {
The following sample bigip.conf files are for an HTTP server with the sole purpose of redirecting requests to the same virtual address on port 443, and using an iRule to change the application protocol from HTTP to HTTPS.
This is a sample HTTP virtual server using a redirect iRule as it existed in the BIG-IP version 4.x big.conf file, before the conversion.
use rule redirect_2_https
Here is the big.conf file after the OTCU converted the settings to Local Traffic Manager version 9.x.
The OTCU incorrectly converted the iRule; it still contains the %h%u syntax used in BIG-IP version 4.x. To correct this iRule, replace the %h%u syntax with [HTTP::host][HTTP::uri], which redirects the connection and keeps the URI intact.
Note: The converted virtual server does not have a default pool, so the TMUI displays the virtual sever as Unknown (blue).
The following sample bigip.conf files are for a default SNAT and a 1-to-1 SNAT, before and after running the OTCU.
This is a sample default SNAT configuration as it existed in the BIG-IP version 4.x big.conf file, before the conversion.
Here is the big.conf file after the OTCU converted the settings to Local Traffic Manager version 9.x.
This is a sample 1-to-1 SNAT configuration as it existed in the BIG-IP version 4.x big.conf file, before the conversion.
Here is the big.conf file after the OTCU converted the settings to Local Traffic Manager version 9.x.
translation 172.24.55.199
origin 10.3.10.199
The OTCU converted the default SNAT to an origin IP and mask of 0.0.0.0, which matches any IPv4 address, because a default SNAT does not exist in Local Traffic Manager version 9.x. Instead, the SNAT is based upon a specified origin IP and mask.
The OTCU modified the SNAT names so they begin with ta0_ because in Local Traffic Manager version 9.x, a SNAT is a named top level object.
Important: The available applications for a SNAT changed considerably in Local Traffic Manager version 9.x. For further details, see the Configuration Guide for BIG-IP® Local Traffic Management.
The following sample bigip.conf files are for a monitors and nodes configuration, before and after running the OTCU.
This is a sample monitors and nodes configuration as it existed in the BIG-IP version 4.x big.conf file, before the conversion.
# type http
use "http"
interval 5
timeout 16
dest *:*
send "GET /search.html"
recv "Query"
username ""
password ""
# type udp
use "udp"
interval 5
timeout 16
dest 192.168.11.1:domain
send "default send string"
sendpackets "2"
timeoutpackets "2"
Here is the big.conf file after the OTCU converted the settings to Local Traffic Manager version 9.x.
When converting these settings, the OTCU applied the monitors to the appropriate pools because in Local Traffic Manager version 9.x, you apply monitors to pools or pool members, instead of to nodes. As a result of this change, the converted file does not contain any node-to-monitor statements.
Local Traffic Manager version 9.x provides the same monitor options as in BIG-IP version 4.x, however the bigip.conf file does not display default (unchanged) settings; consequently, the converted file appears to have fewer monitor object options.
Important: The available applications for monitors changed considerably in Local Manager version 9.x. For further details, see the Configuration Guide for BIG-IP® Local Traffic Management.
Once you migrate your configuration settings and have distributed the configuration to any existing peers, you can remove the OTCU files.
Important: We highly recommended that you perform intensive and careful testing on your system before you remove the OTCU files and put the system back into production.
2.
Type y to remove the directory.
A prompt opens, asking if you want to remove the directory, /var/tmp/otcu_9.x.
3.
Type y to remove the directory.
Note: The script then asks if you want to remove the /usr/bin/otcu.bin directory. Removing the /usr/bin/otcu.bin directory is optional. If you choose to do so, the script removes the file /otcu.ucs.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)