06-Nov-2023 02:50
Dear ALL
Our BIG-IP is currently on v12, and we are planning to replace it with v17.1, with the intention of retaining all configurations. However, due to this major version upgrade, we anticipate that there may be changes in default values. Is there any document available that summarizes the differences for us to review?
Thank you for inadvance.
10-Nov-2023 15:36
Generally defaults do not change. Many times new profiles are introduced howerver to serve as workarounds. Ciphers may change. iRules may need to be updated. SSL ciphers change. Also, that big of a version jump will require a staged upgrade. Please see the following:
https://my.f5.com/manage/s/article/K13845
Generally for this type of work, professional services are recommended. You can also lab test quite a bit using a VE license. You can upload QKView to iHealth for some guidance. If you have an HA setup, complete all work on the standby, failover, and test. Any issues, fail back and tshoot.
Remeber to have active support contract, make sure your hardware supports the latest code, etc.
12-Nov-2023 16:30
Thank you for the reply.
Of course. I knew the professional service, but due to the cost issue, we need to configure it ourselfs.
This time, we plan to replace the hardware with the new R series.
So when we change from v12 to v17.1, we want to know which features have been added, removed, or the default settings have been changed.
For example, the Platform of R-series was changed to Kubernetes etc..
Thank you for in advance.
13-Nov-2023 12:11
I don't believe there is one such document. @whisperer points some things out.
You can go through the release notes of the major version 12.0, 12.1, 13.0, 13.1, ... which will mention many of the changes. But if that is enough for you, not sure.
13-Nov-2023 12:46
You know, Iv been working with F5 since v4.5 and I never really considering many of these issues. Simply too much to consider! More important I think, is having a good test environment, and knowing your applications. One needs to line up an appropriate test plan and have all stakeholders held to the fire in both pre and post upgrade app testing and sign out. Also, always have a revert path to reboot back into the old volume! I think the approach the OP is taking is quite flawed and not setting up anyone for success.