Technical Articles
F5 SMEs share good practice.
cancel
Showing results for 
Search instead for 
Did you mean: 
JRahm
Community Manager
Community Manager

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 0151T000003d7D7QAI.pngsolution, 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!

Comments
Leonardo_Souza
Cirrocumulus
Cirrocumulus

The GUI with repeat button is definitely the easiest way to do, but here is another way to do this.

 

Create virtual server you want via tmsh:

 

root@(LABBIGIP1)(cfg-sync Changes Pending)(Active)(/Common)(tmos) create ltm virtual vs1 destination 10.0.0.200:80 pool pool_http

Go back to history (arrow up), repeat the command with the changes you want:

 

root@(LABBIGIP1)(cfg-sync Changes Pending)(Active)(/Common)(tmos) create ltm virtual vs2 destination 10.0.0.200:443 pool pool_http

Also, you can use the one-line option:

 

root@(LABBIGIP1)(cfg-sync Changes Pending)(Active)(/Common)(tmos) list ltm virtual vs2 one-line ltm virtual vs2 { destination 10.0.0.200:https mask 255.255.255.255 pool pool_http profiles { fastL4 { } } source 0.0.0.0/0 translate-address enabled translate-port enabled vs-index 19 }

Use the line you got to recreate the command, add create, add for profiles and other properties, and lastly remove the vs-index:

 

root@(LABBIGIP1)(cfg-sync Changes Pending)(Active)(/Common)(tmos) create ltm virtual vs3 { destination 10.0.0.200:8443 mask 255.255.255.255 pool pool_http profiles add { fastL4 { } } source 0.0.0.0/0 translate-address enabled translate-port enabled}
JRahm
Community Manager
Community Manager

Nice contribution, @Leonardo! Yes, I forgot the active cli magic available to you.

 

dragonflymr
Cirrostratus
Cirrostratus

Hi,

 

Nice article. Methods mentioned are OK but still Duplicate functionality would be nice addition to the GUI. Most of the time I am using merge way, quite easy and fast but a bit archaic.

 

I know that putting Duplicate function in GUI is not easy but maybe in the future...

 

Piotr

 

Lee_Sutcliffe
Nacreous
Nacreous

I like the edit option from the cli ... (/Common)(tmos) edit ltm virtual http_vs

 

change modify to 'add', rename the VS and change the IP

 

add virtual http_vs1 { . . [esc]wq!

really useful when needing to update lots of things at once too by using the replace options in vi

 

JRahm
Community Manager
Community Manager

ooh, that's a sneaky tweak, didn't know about that one!

 

Version history
Last update:
‎28-Jun-2018 13:30
Updated by:
Contributors