Multiple VIPs on one VS

There is no way to have two destinations under a virtual. I question what the value would add besides not configuring the extra virtual. I assume you have many of them to change. Keep in mind you can have the same pools, profiles, and iRules applied to the two virtuals.

One possible method for large changes is to directly edit the bigip.conf file. Use vi, replace the IPs (ie find and replace all 10.10.10 with 10.10.11), save, then 'b load' or I think the tmsh command is 'load sys config' and it should load up the changes. Watch out for your self IPs on a large scale find and replace.

Thanks Josh.

I figured that it wasn't possible. The value is exactly as you say - not having to create many more VS (we have around 30 all up - not huge, but enough).

It also would give me a graceful cutover - as DNS changes are involved, when clients got the new DNS value, they'd just hit the other VIP but it all goes to the same place.

I tested that it all works perfectly, but only when I create multiple VS.

Thanks though for your time.

Cheers

Just to push the envelope a bit, would it be possible to set up a port-specific wildcard server with an irule that does the redirect for this?

A virtual server can be associated with a /32 address (virtual IP address) or a network /x. In this case you would need an iRule with i.e.:

switch [IP::local_addr] {}

for a granular decission how to treat incoming traffic.

If I may add, one of the most common methods for migrating services is to simply use DNS. In this way you're just flipping a DNS entry from one IP to another, and your VIPs can be anywhere.

Creating 30 virtual from web UI is no fun, I fully agree.

tmsh save sys ucs backup_my_stuff
tmsh load sys config merge file 
tmsh save sys config
tmsh run cm config-sync to-group device-group-failover

i'm going to be going through the same thing. We are moving our public IP's to another block so all of our IP's have to change on the virtual servers and for a period of time both need to be active to handle requests coming in from the old IP while the new IP is being advertised.

It would be so very helpful for F5 to support more than one destination for a virtual server.

Right, it sounds like I need to duplicate the virtual server and change the destination IP and give it a new name... so now I'm dealing with new names for these... or maybe rename the old one.. oh, thats right, they don't let you rename a virtual sever (or much of anything for that matter).

The little irritating things that would make life so much simpler.. awesome product, just a lot of strange, basic things, you just can't do..

How about just creating a file as described by BockyBoy above:

tmsh list ltm virtual | sed -r -e 's/^ltm virtual ([^\{ ]*)/ltm virtual \1_tmp/g' -e '/vs-index .*$/d' > /shared/vs_tmp  

In /shared/vs_tmp you will find a list of all current virtual servers with the extension "_tmp" in their name. Now it´s just about to modify the destination IPs i.e. via vi and to merge the modified file to the running configuration, save and sync.

tmsh load sys config merge file /shared/vs_tmp  
tmsh save sys config

If you can provide a list of old and new addresses by a i.e. comma separated file it can easily be used as a sed-dictionary to automatically replace all destination IPs in the merge file. Please let me know, if I can help with it.

With TMOS v11.6 (available for download now) objects can be renamed according to the release notes.

e.g.

root@(ve11a)(cfg-sync In Sync)(Active)(/Common)(tmos) list sys db mcpd.mvenabled
sys db mcpd.mvenabled {
    value "false"
}
root@(ve11a)(cfg-sync In Sync)(Active)(/Common)(tmos) modify sys db mcpd.mvenabled value true
root@(ve11a)(cfg-sync In Sync)(Active)(/Common)(tmos)
root@(ve11a)(cfg-sync In Sync)(Active)(/Common)(tmos) mv ltm virtual bar newbar
root@(ve11a)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm virtual newbar
ltm virtual newbar {
    destination 172.28.24.10:80
    ip-protocol tcp
    mask 255.255.255.255
    pool foo
    profiles {
        http { }
        tcp { }
    }
    rules {
        qux
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    vs-index 3
}