BIG-IP Upgrade Procedure Using CLI (vCMP Guest & Host)
Problem this snippet solves: Next article describes an upgrade procedure to perform only using CLI commands. The idea is not to replace an official procedure, but to give a different approach for those guys who love using CLI and they want to execute an upgrade only using commands (without GUI access). The procedure is separated in 4 sections: Data Collection & Planning - for executing some days before the upgrade. Pre-Upgrade Tasks - for executing just before the upgrade (applies to all devices in the cluster). Upgrade Tasks - Only applies for one device in the cluster for each time (normally standby device). Post-Upgrade Tasks - for executing just after the upgrade (applies to all devices in the cluster). This procedure is valid for most of the BIP-IP set-ups: Standalone & clusters vCMP Host & vCMP Guests GTM/DNS Synchronization Groups Everything that helps to fix mistakes is great, so your comments are welcome. OFFICIAL REFERENCES: Release Notes - https://support.f5.com/csp/knowledge-center/software/BIG-IP General Upgrade Procedure - https://support.f5.com/csp/article/K84554955 GTM/DNS Upgrades - https://support.f5.com/csp/article/K11661449 VCMP Host Upgrades - https://support.f5.com/csp/article/K15930#p17 HW Life-Cycle - https://support.f5.com/csp/article/K4309 SW Life-Cycle - https://support.f5.com/csp/article/K5903 HW-SW Compatibility - https://support.f5.com/csp/article/K9476 Upgrade Path - https://support.f5.com/csp/article/K13845 How to use this snippet: >> DATA COLLECTION & PLANNING (ALL CLUSTER DEVICES) >> PRE-UPGRADE TASKS (ALL CLUSTER DEVICES) >> UPGRADE TASKS (ONE DEVICE AT TIME) >> POST-UPGRADE TASKS (ALL CLUSTER DEVICES) Code : ###################################################### ## DATA COLLECTION & PLANNING (ALL CLUSTER DEVICES) ## ###################################################### ## Capture Product Code & Serial Number tmsh show sys hardware ## Capture Management IP & Blade State tmsh show sys cluster ## Capture Provision State tmsh list sys provision ## Capture Release and Volume Info tmsh show sys software ## Capture Master-key tmsh show sys crypto ## Check Relicensing Needed tmsh show sys license | grep -i 'service check date' REF - https://support.f5.com/csp/article/K7727 ## Check Certificate Expiration openssl x509 -noout -text -in /config/httpd/conf/ssl.crt/server.crt | grep Validity -A2 REF - https://support.f5.com/csp/article/K6353 ## Check RAID Integrity tmsh show sys raid tmsh run util platform_check cat /var/log/user.log cat /var/log/kern.log ## Check Mirroring Enabled tmsh show sys connection type mirror tmsh show sys ha-mirror ## Check Upgrade Disk Space (At least 20Gb) vgs ## Check ZebOS Module Running vtysh zebos/rdX/ZebOS.conf >> 'X' REPRESENTS ROUTE DOMAIN ID ## ONLY GTM/DNS - Check Devices Managed by GTM tmsh show gtm iquery all ## ONLY GTM/DNS - Check if DNSSEC keys in FIPS are Synchronized tmsh show sys crypto fips ## Capture QKView (Upload to iHealth) qkview REF - https://ihealth.f5.com/qkview-analyzer/ ## Check Release Notes For Specific Details REF - https://support.f5.com/csp/knowledge-center/software/BIG-IP ## Upload Release Image scp -p / @ :/shared/images/ ## Upload MD5 Hash Image scp -p / @ :/shared/images/ ## Upload Script to Check Pool Status scp -p /Check_Pool_Status.sh @ :/shared/tmp/ REF - https://github.com/DariuSGB/F5_Bash/blob/master/Check_Pool_Status.sh ############################################# ## PRE-UPGRADE TASKS (ALL CLUSTER DEVICES) ## ############################################# ## Disable Virtual Server Mirroring REF - https://support.f5.com/csp/article/K13478 ## Disable Config Auto-Sync (if enabled) tmsh modify cm device-group auto-sync disabled ## ONLY GTM/DNS - Disable GSLB/ZoneRunner Synchronization tmsh modify gtm global-settings general { synchronization no synchronize-zone-files no auto-discovery no } ## Save Running Config tmsh save sys config ## Check HA Cluster Synchronization tmsh show cm sync-status tmsh run cm config-sync to-group ## Check Release Image Integrity cd /shared/images/ md5sum -c ## Create Initial UCS (Backup) tmsh save sys ucs /shared/tmp/$(date '+%Y%m%d')_initial.ucs ## Capture Initial Config tmsh save sys config file /shared/tmp/$(date '+%Y%m%d')_initial.scf no-passphrase ## Capture Initial Pool Status /shared/tmp/Check_Pool_Status.sh > /shared/tmp/$(date '+%Y%m%d')_initial_pools_output.txt ## Check No Upgrade Process Running tmsh show sys software status ## OPTIONAL - Get More Free Disk Space (At least 20Gb) tmsh delete sys software volume vgs ######################################## ## UPGRADE TASKS (ONE DEVICE AT TIME) ## ######################################## ## Restart AOM to Prevent Licensing Problems (iSeries) ipmiutil reset -k REF - https://support.f5.com/csp/article/K00415052 ## ONLY VCMP HOST - Check That All Guests Are In Standby tmsh show vcmp guest >> ACCESS INDIVIDUALLY TO EACH GUEST tmsh show cm sync-status ## ONLY VCMP HOST - Deprovision All Guests (Configured) tmsh show vcmp guest >> EXECUTE FOR EACH GUEST tmsh modify vcmp guest state configured tmsh save sys config ## Re-licensing Device >> BIG-IP WITH INTERNET ACCESS tmsh install sys license registration-key add-on-keys { } REF - https://support.f5.com/csp/article/K15055 >> BIG-IP WITHOUT INTERNET ACCESS cp /config/bigip.license /config/bigip.license.backup get_dossier -b -a ** ACCESS LICENSE ACTIVATION https://activate.f5.com/license/dossier.jsp ** PASTE LICENSE FILE (ENTER 'CTRL+D' AFTER PASTING) cat > /config/bigip.license reloadlic REF - https://support.f5.com/csp/article/K2595 ## Force Offline Mode tmsh run sys failover offline ## Verify Configuration Integrity tmsh load sys config verify ## Install Image tmsh install sys software image create-volume volume ## Check Installation State tmsh show sys software status cat /var/log/liveinstall.log ## OPTIONAL - Copy Configuration To New Volume ## (Only if you have made changes since installation) clsh --slot=X,Y cpcfg >> FROM VIPRION cpcfg >> FROM NOT VIPRION ## Boot On New Volume tmsh reboot volume ## ONLY VCMP GUEST - Check Boot Up Status >> FROM VCMP HOST vconsole ## Check Logs (LTM, APM, ASM,...) REF - https://support.f5.com/csp/article/K16197 ## Capture Final Config tmsh save sys config file /shared/tmp/$(date '+%Y%m%d')_final.scf no-passphrase ## Compare Initial-Final Config tmsh show sys config-diff /shared/tmp/$(date '+%Y%m%d')_initial.scf /shared/tmp/$(date '+%Y%m%d')_final.scf | egrep -e "\s{3}\|\s{3}" -e "[<]$" -e "^\s*[>]" ## Disable Force Offline tmsh run sys failover online ## ONLY GTM/DNS - Enable Metrics Collection tmsh start sys service big3d ## Capture Final Pool Status /shared/tmp/Check_Pool_Status.sh > /shared/tmp/$(date '+%Y%m%d')_final_pools_output.txt ## Compare Initial-Final Pool Status diff /shared/tmp/$(date '+%Y%m%d')_initial_pools_output.txt /shared/tmp/$(date '+%Y%m%d')_final_pools_output.txt ## ONLY VCMP HOST - Deploy All Guests (Deployed) tmsh show vcmp guest tmsh modify vcmp guest state deployed ## FROM ACTIVE NODE - Check Current Connections tmsh show sys traffic raw ## FROM ACTIVE NODE - Force Failover Event tmsh run sys failover standby ## Check CPU/Memory status tmsh show sys cpu tmsh show sys memory ## Check Current Connections tmsh show sys traffic raw ## Perfom Other Custom Tests Here ... ############################################## ## POST-UPGRADE TASKS (ALL CLUSTER DEVICES) ## ############################################## ## OPTIONAL - Install Big3d daemon in all managed members ## (Only necessary if you upgrade GTM/DNS before its members) big3d_install REF - https://support.f5.com/csp/article/K11661449#update-big3d ## ONLY GTM/DNS - Enable GSLB/ZoneRunner Synchronization tmsh modify gtm global-settings general { synchronization yes synchronize-zone-files yes auto-discovery yes } ## Re-enable Virtual Server Mirroring REF - https://support.f5.com/csp/article/K13478 ## Synchronize HA Cluster tmsh show cm sync-status tmsh run cm config-sync force-full-load-push to-group ## Re-enable Config Auto-Sync (if enabled) tmsh modify cm device-group auto-sync enabled ## Save running config tmsh save sys config ## Create Final UCS (Backup) tmsh save sys ucs /shared/tmp/$(date '+%Y%m%d')_final.ucs ## Delete Unused Images delete sys software image ## Delete Unused Volumes (Mandatory reboot) delete sys software volume Tested this on version: 12.1Knowledge sharing: F5 Software Upgrade/RMA process
Here is quick summary about things should be checked before an F5 upgrade. This is the general F5 support article with clips and there is nice info for VIPRION and VCMP systems: https://support.f5.com/csp/article/K41125752 https://support.f5.com/csp/article/K84554955 https://support.f5.com/csp/article/K84205182 This a great community article 7 Steps Checklist before upgrading your F5 BIG-IP https://support.f5.com/csp/article/K11661449 https://support.f5.com/csp/article/K13081744 Extra addition to the DNS upgrade is that it is better upgrade first the LTM devices that the DNS devices monitor and after the upgrade of 1 or 2 DNS systems till the other DNS systems are also upgraded better upgrade the big3d process on the older DNS systems in the DNS sunc group: https://support.f5.com/csp/article/K15844889 https://support.f5.com/csp/article/K45907236 https://support.f5.com/csp/article/K13734 https://support.f5.com/csp/article/K13312 For BIG-IQ upgrade or for BIG-IQ to upgrade f5 devices: https://support.f5.com/csp/article/K51342220 https://techdocs.f5.com/en-us/bigiq-8-0-0/managing-big-ip-devices-from-big-iq/big-ip-software-upgrades.html For F5 devices with the F5 APM module after upgrade check if the installed F5 Edge Client software needs to be upgraded as it may not work with the new F5 APM TMOS version. https://support.f5.com/csp/article/K13757 An issue I have seen is to install the new version in a volume and transferring the configuration from the old volume to the new but without activating it and then to activate it after a week and there would an old configuration during that week many changes were done on the old volume config, so better before an upgrade so save UCS just in case from the old volume/partition: Some workarounds: https://support.f5.com/csp/article/K82463047 https://support.f5.com/csp/article/K14724 F5 RMA process general articles: F5 general articles for RMA with or withour UCS as without UCS the system and network settings may need to be configured manually and the configuration to be synchronized from the active device to the rma device. https://support.f5.com/csp/article/K12880 For F5 DNS/GTM there are special steps: https://support.f5.com/csp/article/K14083 F5 RMA of VIPRION chassis or a blade as for example when the new blade is installed but the active software version on other blades and vcmp quests is missing then the blade will get stuck in quorum for the chassis or vcmp quest as the primary blade will not be able to update it. If there is single blade in the chassis better hope that there is saved UCS expecially if there are vCMP quests as then for every vcmp quest the system and network need to be manually configured and the other config can be synchronized from the other chassis and vcmp quests that are in HA cluster. https://support.f5.com/csp/article/K14302 https://support.f5.com/csp/article/K16992 https://support.f5.com/csp/article/K23795307?utm_source=f5support&utm_medium=RSS https://support.f5.com/csp/article/K40222952 As the F5 VIPRION chassis is most complex (see K14302) if there is no saved master key as the vCMP quests use keys that are signed by the vCMP host master key and if it is lost then it is really complex, this is a nice F5 devcentral procedure how to generate your own master key that can be the same for the different F5 VIPRION Devices: https://community.f5.com/t5/technical-articles/working-with-masterkeys/ta-p/290454 When loading UCS on the RMA device that has containing encrypted passwords or passphrases, you can check(I have never used the second article but it is nice to have if issues are seen on a vCMP system when a chassis is replaced): https://support.f5.com/csp/article/K9420 Working with MasterKeys https://support.f5.com/csp/article/K13408 The new F5 Joutneys tool can be used for migrating to configuration to the new F5 VELOS and rSeries platforms and maybe in the future the F5 NEXT Operational System. https://community.f5.com/t5/technical-articles/welcome-to-the-f5-big-ip-migration-assistant-now-the-f5-journeys/ta-p/279673 https://www.youtube.com/watch?v=lLm5OkJRicw For the F5 imish/zebos routing module it is good to renember that that the config is not synchronized in a HA pair and before an RMA/upgrade to run the "write" command in the module as this is like the F5 command "save sys config" for CLI made changes as because of the reboot of the devices this changes can be lost. Before the license reactivation I suggest using the tool https://secure.f5.com/validate/validate.jsp to check that you have legitimate license and support contract.Modernizing F5 Platforms with Ansible
I’ve been meaning to publish this article for some time now. Over the past few months, I’ve been building Ansible automation that I believe will help customers modernize their F5 infrastructure. This especially true for those looking to migrate from legacy BIG-IP hardware to next-generation platforms like VELOS and rSeries. As I explored tools like F5 Journeys and traditional CLI-based migration methods, I noticed a significant amount of manual pre-work was still required. This includes: Ensuring the Master Key used to encrypt the UCS archive is preserved and securely handled Storing UCS, Master Key and information assets in a backup host Pre-configuring all VLANs and properly tagging them on the VELOS partition before deploying a Tenant OS To streamline this, I created an Ansible Playbook with supporting roles tailored for Red Hat Ansible Automation Platform. It’s built to perform a lift-and-shift migration of a F5 BIG-IP configuration from one device to another—with optional OS upgrades included. In the demo video below, you’ll see an automated migration of a F5 i10800 running 15.1.10 to a VELOS BX110 Tenant OS running 17.5.0—demonstrating a smooth, hands-free modernization process. Currently Working Velos Velos Controller/Partition running (F5OS-C 1.8.1) - which allows Tenant Management IP to be in a different VLAN Migrates a standalone F5 BIG-IP i10800 to a VELOS BX110 Tenant OS VLAN'ed Source tenant required (Doesn’t support non-vlan tenants) rSeries Shares MGMT IP with the same subnet as the Chassis Partition. Migrates a standalone F5 BIG-IP i10800 to a R5000 Tenant OS VLAN'ed Source tenant required (Doesn’t support non-vlan tenants) Handles: Configuration and crypto backup UCS creation, transfer, and validation F5OS System VLAN Creation, and Association to Tenant - (Does Not manage Interface to VLAN Mapping) F5 OS Tenant provisioning and deployment inline OS upgrades during the migration Roadmap / What's Next Expanding Testing to include Viprion/iSeries (Using VCMP) Tenant Testing. Supporting hardware-to-virtual platform migrations Adding functionality for HA (High Availability) environments Watch the Demo Video View the Source Code on GitHub https://github.com/f5devcentral/f5-bd-ansible-platform-modernization This project is built for the community—so feel free to take it, fork it, and expand it. Let’s make F5 platform modernization as seamless and automated as possible.
BIG-IP 16.1.x End of Technical Support July 31, 2025
Hello, Community! I wanted to share an important update regarding BIG-IP 16.1.x. As of July 31, 2025, this version will officially reach End of Technical Support (EoTS). If you are on version 16.1.x and haven’t started planning your upgrade, now is the perfect time. Keeping your system on supported software ensures continued technical support, and software development support. Planning ahead can foster a smooth transition. To help you navigate this update I have compiled a list of Knowledge Articles that can assist in planning your upgrade. K000139937: BIG-IP 15.1.x and 16.1.x are reaching End of Technical Support K5903: BIG-IP software support policy K84554955: Overview of BIG-IP system software upgrades K13845: Overview of supported BIG-IP upgrade paths and an upgrade planning reference K18074701: iHealth Upgrade Advisor K7727: License activation may be required before a software upgrade for BIG-IP K16022: Opening a proactive service request with F5 Support If you have any questions, please feel free to leave them below or contact F5 Support for customized assistance. Here we can work together to keep your systems secure, supported, and optimized.Using BIG-IQ to Address the CVE-2020-5902 Vulnerability
As you’re probably already aware, a critical vulnerability was recently discovered within the BIG-IP Traffic Management User Interface (TMUI). In a nutshell, TMUI—sometimes known as the Configuration Utility—has a Remote Code Execution (RCE) vulnerability that can result in a complete system compromise through the ability to: Execute system commands Create or delete files Disable services Execute arbitrary Java code The most critical cases involve BIG-IP systems whose management port and/or self IPs are exposed to the open internet. In these cases, it’s best to assume a breach/compromise scenario and respond accordingly—refer to your organization’s incident response plan. However, even those BIG-IPs that aren’t internet-facing and running in Appliance mode, are still vulnerable.In short, this is an issue that all BIG-IP customers need to address immediately. Fixing the problem F5 has released several resources to help our customers who’ve been affected by this issue. We recommend getting started here on AskF5. In addition to the resources highlighted in the AskF5 article, our DevCentral team has facilitated some video resources and curated answers to the many questions we have received.The first link provides a matrix that outlines which versions of BIG-IP were affected by the vulnerability. To eliminate this issue completely, the recommended course of action is to update/install a new, fixed version of BIG-IP—these fixed versions are listed in the same matrix. If updates cannot be performed quickly, there are other mitigation techniques that can be employed that are listed on the AskF5 article. Leveraging BIG-IQ A couple of the strategies highlighted in the resources above center around BIG-IQ, F5’s powerful solution for unified visibility and management of BIG-IP. BIG-IQ can be especially useful in the context of addressing the CVE-2020-5902 vulnerability as it makes the management of many BIG-IPs much easier and programmatic. With BIG-IQ’s single UI, you can employ two effective CVE-2020-5902 mitigation strategies: Running a bash script on BIG-IQ managed devices Upgrading/updating managed devices to new BIG-IP software versions The bash approach For those that aren’t ready for a full upgrade of their affected BIG-IPs, leveraging a script that mitigates the vulnerability—at least until such time that a highly recommended upgrade can be performed—is a good strategy. BIG-IQ makes this process simple. You can find the script referenced in the video on github - https://github.com/usrlocalbins/Big-IQ-scripts. The upgrade/update approach As we mentioned before, the recommended method is to update your BIG-IP software to a “fixed” version. Beyond CVE-2020-5902, running updated/upgraded versions of software is good practice as it ensures you: Get the latest features and capabilities Are protected from identified threats, vulnerabilities, and bad actors Remain in compliance Are eligible for support and expert help Keep maintenance costs down Sidestep compatibility issues with legacy software The process for updating managed (many) BIG-IPs with BIG-IQ is very straightforward and greatly reduces the time, effort, and manual errors associated with a piecemeal BIG-IP upgrade approach—especially for those with large BIG-IP portfolios. Further Reading To learn more about upgrading your BIG-IPs via BIG-IQ visit the Knowledge Center on AskF5 . Want to learn more about BIG-IQ? You can find more resources—including a no-install demo—at f5.com/bigiqGTM Pool Members Gone After Maintenance? It's Probably This One Setting
You finish a maintenance window, everything looks good on LTM, and then someone notices Wide IPs are resolving to fewer destinations than before. You check the GTM pools and the members are just... gone. The virtual servers are fine on LTM. GTM just doesn't know about them anymore — and more importantly, it doesn't remember if they were ever pool members. This happens more often than it should, and it almost always comes back to the same thing: virtual-server-discovery enabled doing exactly what it was designed to do, at exactly the wrong moment. What's Actually Going On When virtual-server-discovery is set to enabled on a GTM server object, GTM keeps its view of LTM virtual servers in sync via iQuery. It automatically adds new virtual servers, updates existing ones, and — this is the part that causes problems — deletes virtual servers that LTM stops reporting on. That delete behavior is the issue. Any time iQuery reports zero virtual servers, even temporarily, GTM treats it as a mass deletion event. The virtual servers get pulled from the server object, and with them, their pool memberships. When LTM eventually reports on those virtual servers again, GTM re-discovers them as brand new objects with no memory of which pools they belonged to. Two scenarios trigger this consistently. Scenario 1: LTM Software Upgrade This is the one that catches most people. During an upgrade, LTM reboots and goes through a phase where iQuery can connect but the full configuration hasn't finished loading yet. From GTM's perspective, LTM is reachable but reporting no virtual servers. GTM interprets that as a deletion event, clears out the discovered virtual servers, and empties the pools. When LTM finishes loading and the virtual servers come back, GTM re-discovers them — but the pool memberships are gone. You're left manually rebuilding what was there before the maintenance window started. The telltale sign is pool members coming back in blue/CHECKING state. That only happens to newly discovered objects. GTM treated a returning virtual server as a brand new one — because as far as it's concerned, it is. The GTM log won't show a deletion event, only the re-add. That gap in the logs is a known blind spot with virtual-server-discovery enabled, and it's exactly why the problem is hard to diagnose after the fact. What you'll typically see in /var/log/gtm after the LTM comes back: alert gtmd[xxxxx]: 011a1005:1: SNMP_TRAP: Pool your_pool state change green --> red (No enabled pool members available) alert gtmd[xxxxx]: 011a3004:1: SNMP_TRAP: Wide IP your.wideip.example.com state change green --> red (No enabled pools available) And then shortly after, the virtual servers re-appear in CHECKING state as GTM re-discovers them — but with no pool bindings. Scenario 2: LTM HA Failover This one surprises people because the LTM pair is still running — it's just switching active units. After a failover, the new active device may not have its iQuery connections fully re-established yet. GTM sees the iQuery state as inconsistent, virtual server status updates stop coming through, and members disappear from the discovered list. What makes this harder to diagnose is that tmsh show gtm iquery may show "connected" — but connected doesn't mean the config sync is working correctly. In a GTM sync group, only the device assigned local ID 0 (the GTM with the lowest IP address) is responsible for writing auto-discovery results to the configuration. If that specific device loses its iQuery connection during the failover window, discovery events are missed entirely — even if every other GTM in the group can still reach the LTM. So you can have a situation where five out of six GTMs look perfectly healthy, iQuery shows connected everywhere, and yet pool members are still disappearing — because the one device that matters for discovery is the one with the broken connection. You can check which device in your sync group holds local ID 0 with: tmsh list sys db gtm.peerinfolocalid If that device's iQuery connection to the LTM is the one that dropped during the failover window, that's your answer — even if everything else looks fine. The Fix: enabled-no-delete Both scenarios share the same root cause: GTM's auto-delete behavior treating a temporary iQuery disruption as a permanent deletion event. The fix is the same for both: gtm server /Common/site1-ltm { addresses { 10.1.1.1 { device-name site1-ltm } } datacenter /Common/dc1 monitor /Common/bigip virtual-server-discovery enabled-no-delete } With enabled-no-delete, GTM still auto-discovers new virtual servers and keeps existing ones updated. The only thing that changes is that it will never delete a virtual server just because LTM temporarily stopped reporting it. Your pool memberships survive both scenarios above. Mode Adds new VS Updates VS Deletes VS Pool memberships survive iQuery disruption? disabled No No No Yes — nothing changes enabled Yes Yes Yes No — any disruption can empty pools enabled-no-delete Yes Yes No Yes — preserved The Trade-Off enabled-no-delete won't clean up after you when you intentionally decommission a virtual server on LTM. The stale GTM object stays in the discovered list until you remove it manually. In environments with a lot of VS churn, this can accumulate over time. The question is which failure mode you'd rather manage: pool members silently disappearing during a maintenance window, or occasionally needing to clean up stale objects after a planned decommission. For most production environments, the latter is far easier to deal with — and far less likely to wake someone up at 2am. How to Make the Change Via tmsh: tmsh modify gtm server /Common/site1-ltm \ virtual-server-discovery enabled-no-delete tmsh save sys config Via GUI: Go to DNS → GSLB → Servers Select the server object Set Virtual Server Discovery to Enabled (No Delete) Click Update This takes effect immediately and does not affect existing discovered virtual servers or current pool memberships. Cleaning Up Stale Objects When you intentionally decommission a virtual server on LTM, remove the leftover GTM object manually: # List virtual servers under a GTM server object tmsh list gtm server /Common/site1-ltm virtual-server # Remove a specific stale entry tmsh modify gtm server /Common/site1-ltm \ virtual-servers delete { /Common/old-vs-name } tmsh save sys config Make this part of your standard VS decommission runbook and stale objects will never pile up. Quick Diagnostic When Members Go Missing Before assuming it's a discovery issue, check iQuery health across all GTM devices first: tmsh show gtm iquery Look for: State: should be connected to all entries Reconnects: A high count suggests instability even if the connection looks up Configuration Time: None means the config has never successfully synced from that LTM Then confirm which GTM holds local ID 0 and verify its connectivity specifically: tmsh list sys db gtm.peerinfolocalid If the local ID 0 device is the one with the broken iQuery connection, that's your answer — regardless of what the other devices are showing. Wrapping Up Whether it's an LTM upgrade or an HA failover, the pattern is the same: iQuery goes quiet for a moment, GTM interprets silence as deletion, and your pool memberships are gone. It's working as designed — just not in a way that's useful to you. enabled-no-delete is a one-line change that stops this from happening. The cleanup overhead it introduces is predictable and manageable. The alternative — rebuilding pool memberships after an unplanned event — is not. Have you run into either of these scenarios in your environment? Drop a comment below, especially if you've seen the local ID 0 shift cause issues during a rolling GTM upgrade.
Upgrade from 13.1.3.3 to 13.1.3.6
Hi! This weekend, we have encountered some issues with upgrading with 13.1.3.3 to 13.1.3.6 which forced us to cancel the upgrade. When we arrived on 13.1.3.6 the configuration was empty : no VS, no Real Server....empty. One of my guys presumed that the ciphers for SSL on the new version was different than the one of 13.1.3.3 which caused the box to cancel the import of the configuration. Any idea ? thanks!
