Duplicating BIG-IP Objects

Late last night as I was heading to bed I checked twitter (send help, I need an intervention STAT!) and noticed a comment about how to copy a virtual server. I answered in short and he has already arrived at a solution, but I thought this would be a good opportunity to look at a few of the options available to you.

Using the Repeat Button

When using the GUI, an often overlooked feature is the Repeat button just to the left of where most people click Finished. Using repeat will maintain your settings on most objects, so you can just provide a new name and tweak/tune what you need to make a clean new object. In the case of a virtual server like what CISCOGUY is requesting, that’s a new name and a new destination. Everything else can remain the same. This is very handy in saving time and potential human error issues.

It’s pretty cut and dry for like virtuals, but in the case of creating an SSL version of the HTTP virtual, there are some decisions to make. If it is just delivery and not offload, you can’t apply the http profile because it can’t read the traffic. But if you are going to offload, you need to specify a clientssl profile in addition to the name/destination changes.

So for a quick example, I created a virtual bigvip_80 with a destination of 192.168.102.60:80 and enabled only on vlan v102, applied snat automap, set my pool to testpool, and applied source address persistence:

ltm virtual bigvip_80 { destination 192.168.102.60:http ip-protocol tcp mask 255.255.255.255 \
persist { source_addr { default yes } } pool testpool profiles { tcp { } } source 0.0.0.0/0 \
source-address-translation { type automap } translate-address enabled translate-port \
enabled vlans { v102 } vlans-enabled vs-index 5 }

I then hit the Repeat button and changed only the name and destination. To confirm, we can use the tmsh listing to validate the differences with the diff command in the bash shell:

[root@ltm3:Active:Standalone] config # tmsh list ltm virtual bigvip_80 > /var/tmp/bigvip_80.txt
[root@ltm3:Active:Standalone] config # tmsh list ltm virtual bigvip_443 > /var/tmp/bigvip_443.txt
[root@ltm3:Active:Standalone] config # diff /var/tmp/bigvip_80.txt /var/tmp/bigvip_443.txt
1,2c1,2
< ltm virtual bigvip_80 {
<     destination 192.168.102.60:http
---
> ltm virtual bigvip_443 {
>     destination 192.168.102.60:https
24c24
<     vs-index 5
---
>     vs-index 6

The vs-index can be ignored for purposes of configuration.

Editing the Config Files

 Another option available to you is to just manually edit the configuration file. This is not a recommended process, but it can be done. One of the reasons it is not recommended is the number of people who might be making changes to the system simultaneously. If you are editing the file while someone else saves new changes, then you save and load, you might blow their changes away. Or your changes might be blown away if you don’t load fast enough after you’ve saved the file to avoid having them overwritten by someone else. So: possible, but proceed with caution.

Note: Just to clarify when to use config load and config save: when you make a change to the running configuration with a tmsh command, you need to save in order for that change to persist through a reboot. When you edit a configuration file, you have changed the startup config, and need to load in order to activate that configuration change in the running configuration.

The configuration files are in the /config directory (or subdirectories if you are using partitions.) You can use your favorite editor to open the file, which in the case of a virtual server would be /config/bigip.conf for files in /Common partition. My weapon tool of choice is vi, but you are free to choose an inferior one. Simply copy and paste in file, then update the virtual name and destination as before, and make sure to remove the vs-index as that will be auto-generated when you load. Save the file, then load the configuration.

Merging a Config File

 Merging is definitely the way to go if choosing between editing/merging. The process is considered far more safe, and you can even verify that the merge will be successful before going for it. The steps here are to list out the virtual you want to copy (similar to what I did above in the diff,) edit the resulting file with your updates, and then issue:

# Verify
tmsh load sys config file /var/tmp/bigvip_80.txt merge verify
# Merge
tmsh load sys config file /var/tmp/bigvip_80.txt merge

Once your merge is complete you can save to persist to the startup configuration.

Automating via iControl

Finally, you can use automation tools to do the heavy lifting for you via an imperative process like my python script I wrote in my merging BIG-IP config files article, or via the python sdk far more simply with:

mgmt_root.tm.sys.config.exec_cmd('load', options=['file':'/var/tmp/bigvip_80.txt', 'merge':true}])

Assuming your file is there already, you can also upload the file via the sdk.

For a more declarative option, you can use tools like Ansible and then you are just defining a playbook with the important stuff, like names, destinations, profiles, and the tools build everything for you.

What other ways are you duplicating BIG-IP objects? Share below with the community!