Mar 27, 2026 - For details about updated CVE-2025-53521 (BIG-IP APM vulnerability), refer to K000156741.

Forum Discussion

Josh_41258's avatar
Josh_41258
Icon for Nimbostratus rankNimbostratus
Nov 15, 2012

DEV/QA/TEST Implementation

We are consolidating several older hardware platforms on to the VIPRION+vCMP platform in our datacenters. I'm curious as to what others are using for their DEV/QA instances of BIG-IP? We currently use an older pair of 6400's for this, but now they are EOL and can't support 11.2+. I have considered running a pair of VE edition BIG-IP+LTM's on our ESX infrastructure for DEV and QA since traffic requirements are minimum.

 

I have also considered carving out another vCMP guest for DEV/QA, but I don't want to waste a guest slot, and I prefer to have DEV/QA completely isolated from the vCMP/VIPRION environment.

 

What are others doing?

 

Thanks,

 

Josh

 

4 Replies

  • pete_71470's avatar
    pete_71470
    Icon for Cirrostratus rankCirrostratus
    Nov 15, 2012
    Our primary HA pair are Viprions and we use ESX for dev and qa. The LAB version of LTM for ESX is inexpensive but has significant bandwidth limitations and can't be used for production traffic. It also doesn't let you test and pre-deploy features that tend to break when performing upgrades on the Viprion. Simple network HA between to VMs works just with hardware. Overall, using the virtual versions has worked quite well for us.
  • Josh_41258's avatar
    Josh_41258
    Icon for Nimbostratus rankNimbostratus
    Nov 15, 2012
    Pete,

     

     

    So you are not using the LAB version? Do you have a pair of virtual LTM's and configure Network Failover/HA between them?

     

     

    Thanks
  • pete_71470's avatar
    pete_71470
    Icon for Cirrostratus rankCirrostratus
    Nov 15, 2012

    We are indeed using the LAB version: LTM, Lab, V with 11.2.1HF1. There are two virtual LTM's with network (unicast) failover. We have two traffic groups with one running on the Active unit and the other on the Standby, allowing us to fail over traffic groups independently.

     

    Snapshots on the ESX server have been disabled; unexpected failovers can happen if the network interfaces are quiesced for too long. We have an external process that downloads ucs archives and imports them into rsnapshot so having ESX snapshots isn't necessary.

     

    The only problematic issue we've come accross is related to vMotion. F5 has sensible precautions concerning potential traffic disruptions during a vMotion. For us, right after one of these magical events the trust between the two virtual LTM's exploded into tiny little shards. It's probably best pinning the LTM's to specific ESX servers to avoid it altogether.