Last Modified: Apr 28, 2025
Affected Product(s):
BIG-IP vCMP
Known Affected Versions:
11.5.0, 11.5.1, 11.5.1 HF1, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.5.10, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3
Opened: Nov 04, 2016 Severity: 4-Minor
In a bladed vCMP system with guests spanning several blades, there is an issue when concatenating output from applications via blade console/virtual console. The timing issue is presumably that if the host is not processing fast enough to process the data sent by a guest application to the virtual console the host will suffer high load, causing the primary blade to clockadvance, miss its heartbeat, and be removed from the cluster.
Blade may stop working after executing the command.
-- In a large configuration (for example, 55 virtual servers with corresponding pools, persistence profiles, and iRules). -- Run the following tmsh command: tmsh show ltm virtual detail
Upgrading hypervisor to 12.1.1 or later resolves the issue.
None