This is a simplified check list for GTM & LTM deployment based on my experience.
Don’t deploy GTM in HA pair in a single DC:
GTM devices work in a synchronization group across geographic regions. If you deploy GTM-1 in DC-1 and GTM-2 in DC-2, these 2 GTM devices will serve as Active-Active HA Pair for most deployments.
There is no reason to have GTM-1A & GTM-1B in DC-1 and GTM-2A & GTM-2B in DC-2, where the A & B devices are part of an HA pair. Option-B design is just an overkill.
GTM to LTM VS Health Monitors:
Let the LTM monitor its pool members. The GTM will obtain the status of the LTM pool members from the LTM. GTM directly monitoring the LTM pool members or LTM VS is not required in most cases.
Don’t deploy LTM in Active-Active state:
There is a lot of room for flexibility with this statement. I haven’t found the Active-Active pair to be reliable in production environment. Such deployments are rare in the industry and hence, if there are any bugs with Active-Active pair, there is a greater chance that your deployment could be affected by the software bug than the Active-Standby setting which is widely deployed and stable.
Code Upgrade Checklist:
- Check license reactivation date before code upgrade.
- Check to make sure that the code you are utilizing is not End of Support.
- Save the configuration on the box and outside the box whenever upgrading code.
- Save the license number on the box in a /var/tmp file and off the box.
Code Version:
You are better off picking one of the Long Term Stable code version releases as provided in this K5903.
Route Domains:
Route domains are F5’s version of VRF. Although they are easy to deploy, they can be a pain to troubleshoot with the “%” addition to IP address.
iRule Vs LTM Policy:
My personal preference is always iRule as it provides greater granular control and flexibility. However, LTM Policy may be better optimized and can provide lower latency for the same function. LTM Policy can be an effective substitute for simple iRules.
Pool & Pool Members:
As a rule of thumb, all the members in a pool should have the same port. For example: POOL_WEB_80. This naming convention tells you that this is a pool of web servers that are listening on port 80 even without looking into the individual pool members. Having multiple members listening on a common port as part of a single pool helps in the long run to scale the configuration without adding significant operational complexity.
Naming Convention:
While creating custom VS, Pool, Monitor etc, I recommend starting with capital letters. For example:
POOL_Web_80
VS_domain.com_80
VS_domain.com_443
MON_HTTP_80
The default configuration elements like tcp, http monitor tends to be lower case in F5. The capital letters helps to distinguish between user-created (custom profiles) and default profiles which are all lower-case.
Custom & Default profiles:
NEVER use default configuration elements. Create custom configuration elements with the default configuration elements as parent profile.Whenever configuration change is required, always change only the custom profiles. This will prevent someone from accidentally changing the default profiles while working on the F5.
