Testing strategies for f5 bigip

Ideally, you should have an F5 BigIP in your (production parallel) staging environment. This allows you to test new configuration, code versions, features, etc without impacting production.

Assuming that this is not possible due to cost or other constraints, then the next best alternative would be to have a second set of 'QA' or 'UAT' services that is configured to hit the same back-end servers as production, but only has a small fraction of users targetting it.

Without knowing more about your configuration, it's difficult to be more specific. Are you able to provide a bit more detail as to how you are using your load-balancer, and what changes you are planning to make?

UPDATE: based on your clarification, it seems that you want to test your ability to flip users between one set of back-end servers and another, and that you are routing user requests based on the URL they are accessing? (Content switching).

If you are unable to afford another load-balancer in production, I would suggest configuring a new service using a test URL, and forwarding the requests to that URL the same as you do in production currently. Once you are happy that this test service is working as per production, you can change the policy associated with the test URL to forward to your new backend. This should verify that your Big-IP configuration is correct.

(Apologies for the lack of sample configuration, I've not worked with F5 load-balancers myself, only other vendors.)

You can get a time (and some functionality) limited virtual edition of LTM that will run in vmware:

https://www.f5.com/trial/

Or a test virtual server on the production unit(s) is a good alternative.

Other load balancers offer similar functionality to F5, and their vendors provide more useful test and development options.

You can get a development license for Zeus Traffic Manager (full functionality) or a Citrix VPX license (standard edition only), both limited to 1 MBits throughput (which should be adequate for most development purposes), and valid for 1 year.

Zeus will renew development licenses yearly at no charge (don't know what Citrix will do?)

Aaron - under no circumstances is a test virtual server on a production unit a good alternative!

I do this by setting up a second virtual (or set of virtuals) that are mapped to the same pools. You can then test the staging VIP by editing your /etc/hosts file (or Windows hosts file).

At this point I'll sing the praises of my outsourced DNS provider, Dynect (http://dynect.com). They have a Traffic Management feature that allows you to add both the old and new VIPs to a hostname rotation, but also adjust the weighting - the ratio of how often the old vs new IP is served, and then you can raise the weight to slowly migrate if a hard cutover is too risky.

For internal DNS, I believe that F5's GLB can do the same thing (but don't quote me as I don't have hands-on experience here).

Having a test environment is the first answer.

I recommend to automate testing with any HTTP scenario injection tool.

Then comes the question how to keep your environments in sync, and I recommend to give up manual setup on production environment from admin interface.

Proposals to automate BigIP setup the DevOps way are:

• iApp created by F5 https://clouddocs.f5.com/api/iapps/

• Ansible modules https://www.ansible.com/integrations/networks/f5

• Terraform ressources https://www.terraform.io/docs/providers/bigip/index.html

• design your own iApp

Or course applications created from iApp (either from F5 or your own) must be deployed thanks to either Ansible or Terraform.

At the time of writing this, neither Ansible modules nor Terraform ressources cover all BigIP configuration entities yet.